воскресенье, 7 августа 2011 г.

Мобильный телефон в качестве доверенной среды ДБО

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

Алгоритм:
1)      Клиент составляет ПП в своей бухгалтерской программе
2)      Клиент передает ПП из бухгалтерской программы в Клиент-Банк
3)      Клиент-Банк запрашивает пароль
4)      Если пароль верный Клиент-Банк преобразует информацию из ПП в QR-код или аналогичный и выводит его на экран ПК
5)      Клиент запускает специальное Приложение на мобильном телефоне.
6)      Приложение фотографирует и распознает QR-код с экрана ПК
7)      Приложение выводит на экран мобильного телефона основные реквизиты ПП (кому/сколько)
8)      Клиент проверяет основные реквизиты и если все верно нажимает «зеленую» кнопку на мобильном телефоне (если нет, то на «красную»)
9)      Приложение генерирует ЭЦП, на основе данных ПП и закрытого ключа клиента (закрытый ключ клиента интегрирован в Приложение) и отправляет его в виде SMS в банк
10)  Клиент-Банк шифрует ПП и отправляет в банк
11)  Банк при получении ПП расшифровывает ПП, проверяет ЭЦП и отправляет клиенту подтверждение о принятии платежа
Плюсы данного решения:
·         Двухфакторная аутентификация
·         Низкая цена устройства
·         Низкая стоимость разработки Приложения
Минусы данного решения:
·         Зависимость от поставщика мобильных услуг
·         Дополнительное устройство

пятница, 5 августа 2011 г.

В чем польза сертификата?

Хочу здесь высказаться не в унисон большинства специалистов по информационной безопасности, кроме, разве что производителей СЗИ и их интеграторов.
В новом законе о ПДн говорится, что для защиты ПДн должны использоваться средства защиты, прошедшие оценку соответствия. Однако не говорится, оценка на соответствие чему и как она должна быть проведена. Есть следующие способы ее достичь:
1.       Сертификация по НСД, НДВ, ОУД и так далее
2.       Международная сертификация, например всё те же EAL

 

По вопросам первой, добро пожаловать к нашим регуляторам. По вопросам второй никуда ходить не надо, т.к. она в России не признается. А зря!
Сертификат на СЗИ минимально гарантирует, что продукт проверен на заявленный функционал, на отсутствие недекларированных возможностей, на безопасность. Таким образом, можно говорить об уровне доверия к СЗИ. Я могу привести много российских СЗИ известных компаний, которые и близко нельзя подпускать к критичной информации и наоборот. А ПДн и относятся к конфиденциальной информации, однако, в  российских реалиях такое соответствие не является аксиомой, так как до сих пор любые базы данных имеются в свободной продаже и решения этого вопроса пока не предвидится.
Использование сертифицированных СЗИ является особенно актуальным для защиты каналов связи. Любые организации, имеющие филиальную сеть должны обеспечивать конфиденциальность при передаче ПДн через незащищенную сеть Интернет. Сейчас на российском рынке уже представлено достаточно СЗИ данного типа (Континент, Випнет, СТерра, и др.), они покрывают большинство нужд ИТ. В общем случае криптография предоставляет более высокий уровень доверия по сравнению с любым логическим разграничением прав доступа, и по этой причине, я считаю, требования регуляторов в части криптографии справедливыми.
По вопросу использования «обычных» сертифицированных средств, таких как MCЭ, АВ и других, мне видится, что  должен быть баланс на основе таких критериев как: объем, критичность, тип данных, другими словами реализация должна зависеть от модели угроз.
По вопросу использования других (специализированных) сертифицированных средств я энтузиазм закона не разделяю. Например, зачем мне сертификат на DLP или SIEM или IDM? Это высокоуровневые системы, безопасность которых и достигается «обычными» СЗИ.
Ну и, как мне кажется, регуляторам следовало бы признавать международную сертификацию по общим критериям, Правда процесс признания должен быть обоюдным, а для этого нужно перестать нашим регуляторам выдавать сертификаты на неработоспособные СЗИ.

вторник, 2 августа 2011 г.

Критерии работы службы ИБ

Согласно Wikipedia «Ключевые показатели эффективности (KPI) — система оценки, которая помогает организации определить достижение стратегических и тактических (операционных) целей. Использование KPI дает организации возможность оценить свое состояние и помочь в оценке реализации стратегии».

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