понеділок, 13 грудня 2010 р.

Методика оценки рисков ИБ от НБУ


На выходных просмотрел  проект «Методики оценки рисков информационной безопасности» изданный Национальным Банком Украины.

Хорошо, что у нас не принято указывать автора документа, не то можно было бы смело «ставить крест» на карьере методиста столь замечательного опуса.

При  разработке Методики авторы руководствовались  стандартом ISO/IEC 27005:2008 "Information technology - Security techniques - Information security risk management". Стандарт представляет собой высокоуровневый документ, который  хорош как некое концептуальное ядро, требующее методологического сопровождения, чего, откровенно говоря, не получилось:
крайне плохой (а часто некорректный) перевод текста стандарта, абсолютно неудачное сокращение  текста  (из более 50 страничного стандарта была создана 17 страничная методичка со шрифтом мене убористым, чем в оригинале) привел к результату, когда есть много сомнений возможности практического использования документа, особенно в организациях, где оценка рисков информационной безопасности будет проводиться впервые.

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

Что не понравилось и что бы хотелось бы исправить:
1. Убила первая фраза Методики, оказывается, что внедрение в банках Украины стандартов ИБ продиктован требованиями Базельского комитета. Даже если это правда, ни ужели на сегодняшний день нет других причин внедрять стандарты ИБ?  Нужна более сильная мотивация.
2. Ввиду того, что обсуждается Методика (а не, например, стандарт) и идет ссылка на нормативные требования Basel II, следовало бы, более подробно остановится на рисках, которые могут возникать в результате нарушений ИБ. Потому как операционные риски, в данном случае могут вызывать - юридические и репутационные риски. А согласно §732 (Базеля): В процессе оценки достаточности капитала должны учитываться все существенные риски, с которыми сталкивается банк.
3. Обязательно должен присутствовать раздел терминологии, который, в свою очередь должен согласовываться с ранее принятыми НБУ стандартами (СОУ Н НБУ 65.1 СУІБ).
4. Проиллюстрировать процессы оценки и обработки рисков графически, сопроводив более подробным описанием.
5. Отдельным пунктом вынести требования по организации необходимого обмена информацией связанной с Рисками ИБ (см ISO/IEC 27005:2008 -  §11 Information security risk communication)
6. Количественные оценки требуют формул. Решение, авторов Методики, о замене формулы ее словесным описанием мне кажется крайне неудачным.
7. Может оказаться полезным введением и пояснением терминов Single Loss Expectancy (SLE), Annual Rate of Occurrence (ARO), Annual Loss Expectancy (ALE), Risk On Security Investment (ROSI), и т.п. Потому как, при выборе банком иностранной методики оценки информационных рисков, желательно не допускать разночтений в терминах при аудите.
8. Почему не анализируются риски связанные с нарушениями в части "автентичності" та  "спостержності"?
9. Проиллюстрировать примерами качественную и количественную оценку рисков.
10. Еще раз критически посмотреть на неиспользованный материал ИСОшного Стандарта.
11.

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

четвер, 18 листопада 2010 р.

А что тут такого? Нам некогда

В течение месяца по внутренней почте Клиент-Банка от группы технической поддержки получаю ТРЕТЬЕ письмо о необходимости проверить версию ПО Клиента и обязательно, если она не последняя, обновить согласно приложенной инструкции.

У меня версия правильная, причем правильная на момент первого сообщения. В связи с этим возникает два вопроса:
  1. А что Банк не видит версию моего клиента?
  2. Или он в соответствующих журналах не видит, что я обновился?

Мало того, что Банк демонстрирует низкую управляемость процессами, так он еще факт, отсутствия  контроля над ситуацией, «вбивает в голову» (письмо то уже третье).

А может я это зря? Может так и должно быть?

Не корысти ради...

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

Короче, решил как все, а что из этого получится – посмотрим…