пятница, 31 декабря 2010 г.

С новым Годом

Поздравляю всех читателей с Новым Годом!

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

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

Веселого празднования!


воскресенье, 26 декабря 2010 г.

Безопасность без границ: результаты для Украины

Наконец-то дошли руки не только перевести основные наблюдения из международного  исследования Ernst & Young по информационной безопасности за 2010, но и сравнить общемировую картину с ситуацией в Украине, провести бизнес-завтрак на эту тему, и, не прошло и двух недель, выложить результаты на блог. 
Достаточно интересно было сравнить отношение украинских компаний* к технологиям "размывающим границу компании" - облачным вычислениям, мобильным вычислениям и социальным сетям.
Так, например, к облачным вычислениям украинские компании относятся весьма осторожно - ни одна из опрошенных не использует и не планирует использовать публичные облака. К наличию сертификата по безопасности у провайдеров облачных вычислений, как к гаранту защищенности данных, украинские компании также относятся более прохладно, чем "общемировая" общественность.
Любопытно было также наблюдать за тем, как компании собираются реагировать на новые риски. Общемировая общественность собирается изменять политики (добавлять туда новые риски) и внедрять программы по повышению осведомленности пользователей. Украинские же компании уповают на шифрование и дисциплинарные процессы.  Впрочем не буду пересказывать содержание, а просто выложу материалы.

* В исследовании принимали участие 32 украинские компании, половина из которых - банки

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

Интегрированное общекорпоративное управление рисками от NIST

800-я серия стандартов по информационной безопасности от National Institute of Science and Technologies дополнилась проектом нового стандарта по управлению информационными рисками.

На смену старому доброму SP 800-30 Risk Management Guide for Information Technology System приходит новый SP 800-39 "Integrated Enterprise-Wide Risk Management: Organization, Mission, and Information System View". SP 800-39 стандарт заменит SP 800-30 в вопросах управления рисками. Сам же SP 800-30 будет пересмотрен в следующем году и будет віполнять роль вспомогательного стандарта, сосредоточившись сугубо на вопросах оценки рисков.

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

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

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

воскресенье, 12 декабря 2010 г.

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

Указом президента Украины № 1085/2010 "Про оптимизацию системы центральных органов исполнительной власти" среди пары десятков других служб и агентств создается  государственная служба Украины по вопросам защиты персональных данных. Деятельность созданной службы координируется Кабинетом Министров Украины через Министра юстиции Украины.

Первый шаг после принятия закона о персональных данных сделан. Ждем детальной законодательной базы...

четверг, 9 декабря 2010 г.

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

- Скажите, пожалуйста, куда мне отсюда идти?
- А куда ты хочешь попасть? - ответил Кот.
- Мне все равно... - сказала Алиса.
- Тогда все равно, куда и идти, - заметил Кот.
- ...только бы попасть куда-нибудь, - пояснила Алиса.
- Куда-нибудь ты обязательно попадешь, - сказал Кот. - Нужно только достаточно долго идти.

Вчера Национальный банк разослал  проект методики оценки рисков информационной безопасности. Стандарт базируется на международном стандарте ISO/IEC 27005 "Information technology - Security techniques - Information security risk management" и дополнен изрядной долей креатива.

По форме.
Обычно при подготовке к выпуску какого-либо продукта, если не укладываются в сроки, жертвуют качеством. С расчетом "потом поправим". Прочтение документа оставляет впечатление, что дефицит времени был колоссальный. Соответственно,  это прямо пропорционально отразилось на качестве. Можно закрыть глаза на не убранные "track changes" и не везде переведенные с русского термины. Но это только начало. Конфиденциальность, целостность, доступность и  наблюдаемость  из свойств информации (точнее свойств ресурсов СУИБ, определение из стандарта ) превратились в сервисы информационной безопасности.
Приложения с примерами, изначально задуманные для упрощения понимания методики, запутают даже опытных специалистов по управлению информационными рисками. Как, например отличить социальную инженерию, используемую для промышленного шпионажа, от социальной инженерии, используемой хакерами и кракерами? То, что кракеры используют социальную инженерию повергнет в шок даже самих кракеров. А как отличить хакеров от компьютерных преступников? Которые могут быть только внешние, ибо инсайдеры - это отдельная категория. Этот список можно продолжать бесконечно: DOS и DDOS атаки теперь сугубо террористическая деятельность, "Відсутність схем періодичної замени" может привести к "Руйнуванню обладнання або середовища" и т.д. В раздел "ляпы" можно переносить львиную долю приложений. 

По сути.
Практической пользы от документа крайне мало. Для тех, кто не знал какую методику использовать, ответа на вопрос "что делать?" в документе нет. Есть туманные путанные противоречивые намеки. О том, что методики оценки есть качественные и количественные. И жесткого предписания что именно использовать нет. Есть только описание плюсов и минусов различных подходов.  Что есть хорошо и плохо одновременно. Хорошо для банков, которые имеют свои методики. Почти любая методика оценки информационных рисков, выпущенная после изобретения компьютера подойдет под требования. А плохо в том, что те кто не знал как оценивать риски, не поймут этого даже после троекратного прочтения документа. Суть некоторых предложений, благодаря их длине и вложенности, становится понятна только после их третьего прочтения.
Основные преимущества, от использования риск-ориентированного подхода тоже под угрозой. Если банки смело могут использовать качественную оценку (дескать она проще), как оценить эффективность инвестиций в контроли? Да, НБУ предупреждает о недостатках сугубо  качественной оценки рисков. Но не запрещает ее использование. По сути - это дыра для тех кто просто хочет соответствовать требованиям не заворачиваясь.
Суть документа можно свести к следующему: "используйте любую методологию, а не знаете как - идите к консультантам.". А консультанты уже тут как тут - прислали коммерческие предложения по оценке рисков раньше, чем НБУ проект методологии. И у всех "опыт внедрения". Не важно, что внедряли антивирус, зато "в соответствии с требованиями ISO 27001", что в предложении отражается как "практический опыт внедрения ISO 27001".

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

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

Впечатления от USIG V

В пятницу прошло 5-е собрание linkedin'овской группы USIG (Украинской группы специалистов по информационной безопасности).
Мероприятие прошло хорошо. Растет количество заинтересованных специалистов. Из порядка 500 мифических членов группы, фигурирующих только в ее списках, вырисовываются 50-60 профессионалов готовых обсуждать насущие вопросы информационной безопасности.

Собрание поддержал украинский чаптер ISACA. Хотя от "поддержки" осталось двойственное впечатление.
Во-первых, от чаптера пришли только президент и вице-президент (еще ваш покорный слуга и коллега, но мы бы пришли вне зависимости от участия чаптера). И это из почти 60 членов, которые были приглашены на мероприятие.
Во-вторых, исследование, проведенное и представленное чаптером... Вроде провели исследование по важным вопросам управления ИТ. Тема действительно актуальная. Что такое IT governance  понимают далеко не все, кто должен понимать. Даже перевода устоявшегося нет. И исследование проводила ISACA - одна из передовых международных ассоциаций, призванных нести светлое будущее ведущие мировые практики по управлению ИТ в массы. Но во время презентации, почему-то в голову все время закрадывалось подозрение, что король голый.
Кто были респонденты исследования и на сколько репрезентативна выборка осталось тайной, покрытой мраком.
Некоторые  наблюдения, выводы и рекомендации навевали на мысль, что исследование делалось в докризисные годы, упало за шкаф, потерялось, и только теперь его нашли и решили показать общественности.
Взять хотя бы рекомендации (напомню, что речь шла о 9 наиболее приоритетных направлениях) о формализации ИТ-стратегии. Какая, простите, ИТ-стратегия, если в бизнес стратегия есть только 30% компаний (речь шла преимущественно о банках)?!?  На основании чего, простите, ее составлять?
Или мысли о том, что ИТ - это конкурентное преимущество компании? Друзья мои! ИТ было конкурентным преимуществом, когда не каждая компания могла его себе позволить. Так же как и электричество во времена паровых двигателей. Сейчас чуть-чуть все по другому.
Банки, кстати, уже не являются безусловными лидерами по информатизации. Многие компании из других секторов экономики, например,  FMCG компании, могут похвастаться более современными и зрелыми процессами и решениями.
Бизнес не может сформулировать ИТ чего он хочет? А должен ли? А может это ИТ должно понимать как работает бизнес-процессы и предлагать как ИТ может помочь их улучшить?
В общем, спасибо, что нашли время для исследования и рассказа.
Завершилось выступление тоже туманно. Вроде прозвучал призыв помогать развивать чаптер. Даже вызвались желающие. Но конкретики так и не прозвучало. После оспаповского "о дне следующего заседания будет сообщено дополнительно" мы расстались...

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

Мой доклад был посвящен эффективному построению процесса управления информационными рисками. Хотя приводимая методика годится для построения процесса управления рисками и других видов.
Материалы прилагаю.


P.S. По мотивам чаптеровского выступления вспомнились пару хороших книг (не очень свежих - лет по 7 каждой, но все еще актуальных), которые я  рекомендую почитать :
  • Nicholas G.Carr "Does IT Matter?"  На тему является ли ИТ конкурентным преимуществом
  • Terry White "What Business Realy Want From IT?" на тему должен ли бизнес объяснять ИТ чего он хочет
P.P.S. Нет все-таки устоявшегося понимания чем же мы занимаемся. 70% докладов были посвящены ИТ -безопасности 30% - информационной. Нет еще единого понимания, что информационная безопасность - это безопасность информации, а не ИТ. И это - основная проблема, почему нет поддержки от бизнеса. Но об этом в другой раз...

четверг, 2 декабря 2010 г.

Украинский чаптер ISACA: перезагрузка

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

На завтрашнем собрании UISG  планируется активное участие правления и членов чаптера, обсуждение будущих планов чаптера.
Что же. Приятная новость. Надеюсь, что от разговоров до дела переход не затянется и чаптер начнет функционировать так, как он когда-то задумывался.

Историческая справка:
За последнее время деятельность чаптера практически не велась. Исключение составляли точечные публикации в прессе и выступления на профильных мероприятиях. Кризис сказался и на чаптере. Приятное исключение составляла работа Андрея Лысюка, который координировал вопросы проведения сертификационных экзаменов.
На текущий момент украинский чаптер насчитывает 59 членов. 39 специалистов имеют сертификаты ISACA (33 CISA, 6 CISM и 3 CGEIT).

Остальные детали завтра.

суббота, 27 ноября 2010 г.

Требования НБУ - можно ли их выполнить?

Под таким девизом прошло на этой неделе заседание клуба БИТ (Клуб Банковских IT-Менеджеров).
На повестке дня было обсуждение подходов по внедрению двух банковских стандартов по информационной безопасности.

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

Пользуясь случаем, расспросил у Ирины Сергеевны смущающие меня места в методических рекомендациях. Речь идет о документе, который  Национальный банк недавно опубликовал  - "методические рекомендации по внедрению системы управления безопасностью в соответствии со стандартами Национального банка Украины". В силу того, что документ имеет статус проекта, банки все еще имеют шанс внести свою лепту и прокомментировать либо дополнить не понравившиеся фрагменты. Времени на это есть еще две недели - до 6 декабря.
Основные моменты нашей беседы  с Ириной Сергеевной (ИС):
  • Раздел 4.1 Классификация информации (стр.4) Мое врожденное занудство Моя педантичность не позволила пройти мимо того факта, что методические рекомендации содержат разъяснения только по поводу классификации по конфиденциальности информации. Ни слова про целостность и доступность. А стандарт требует. Создается благоприятная почва для того, чтобы понять не правильно и упростить себе жизнь. По крайней мере попробовать.
    Комментарии ИС
    - стандарт все равно требует - делать нужно.
  • Раздел 4.1 Описание критичных бизнес процессов... (стр.5) Рекомендации касательно того, что для каждого бизнес-приложения должен быть определен бизнес-владелец. Рекомендовано один. Естественный вопрос - кто владелец ОДБ?
    Комментарии ИС - возможно определение группового владельца.
    Размышления по следам - коллективный владелец - коллективная безответственность ответственность. Задача по классификации информации и другим решениям будет достаточно не тривиальной задачей, если мы вдруг захотим построить эффективную СУИБ
  • Раздел 4.1  Описание организационной структуры, которую охватывает СУИБ (стр.7). Понятно, что взято из 27003. Вопрос зачем? В стандарте украинским по-белому написано - "весь банк". Вопрос риторический. Идем дальше.
  • Раздел 5.2 Оценка рисков (стр.9) Упоминается загадочная методика оценки рисков. Вопрос какая?
    Комментарии ИС - НБУ разрабатывает собственную методику оценки рисков. Выйдет в январе. Вопрос будет ли она обязательной - вопрос не решен. Методика отличная от IRAM (один из кандидатов рассматривающихся ранее) и при этом более сложная.
    Размышления по следам - Консультант в своем докладе упомянул, что будут использовать собственную методику оценки рисков в деньгах. Для меня осталось загадкой, что банк будет делать с купленной оценкой, если в январе НБУ вдруг скажет, что оценка должна выполняться  только по их методике. С другой стороны, Нацбанк вряд ли будет выкручивать руки и делать свою методику единственно допустимой. Ждем января.
  • Раздел 6.3 Документы верхнего уровня (стр. 12) Вышеупомянутое занудство Вышеупомянутая педантичность не позволила пройти мимо описки. В описании первой группы верхнеуровневых документов (второй абзац раздела) упоминается стратегия развития банка. На самом деле, имеется в виду стратегия информационной безопасности.
    Комментарии ИС - в тексте допущена описка. Необходимо исправление.
  • Раздел 6.4 Документы среднего уровня (стр. 14) В разделе А12 меня смутил документ "Описание процедур управления ключевой информацией". Долго ломал голову "что это за информация?". Оказалось все банально - речь идет о криптоключах.

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

P.S. Да, совсем забыл. Вопрос сезона: "Что будет за несоответствие". Ирина Сергеевна сообщила, что НБУ пересматривает список санкций, применяемых банкам "за невыполнение" с учетом новых стандартов. Но что там будет - пока секрет. Не нужно быть Капитаном Очевидность, чтобы понять, что если санкции не серьезные, банкам легче платить штрафы, чем выполнять дорогостоящие рекомендации стандартов. Ждем января и официальных комментариев НБУ.

P.P.S. В 27001 есть одна лазейка, которая позволяет растягивать удовольствие от внедрения стандарта на несколько лет, при этом ежегодно обеспечивая полное соответствие. О нем, кстати, Ирина Сергеевна тоже неоднократно напоминала. Нет денег на внедрение? Выход прост:
  1. Делаем подготовительную часть (назначаем ответственных, делаем документы верхнего уровня)
  2. Проводим инвентаризацию и классификацию ресурсов СУИБ (термин из стандарта, т.к. слово "активы" не прижилось из-за конфликта с "банковскими активами")
  3. Проводим оценку рисков
  4. Финальная часть - осознаем наши риски  их и принимаем (в соответствующем документе). В стиле "Мы, руководство банка находясь в здравом уме и трезвой памяти, знаем о рисках блаблабла  и принимаем их на текущий год по причине отсутствия средств на контроли."
  5. Все, до следующего года мы соответствуем.
  6. Занавес
P.P.P.S. Отдельное спасибо хочется сказать за раздел 7. Внедрение и функционирование СУИБ. Стандарт требует на ежегодной основе проводить внутренний аудит СУИБ. Логичный вопрос - где банки возьму сразу столько специалистов? Методические рекомендации отвечают на данный вопрос лаконично: нет своих - привлекайте внешних. Консультанты  на несколько лет вперед работой обеспечены.

четверг, 18 ноября 2010 г.

ALL OVER ANTIRISK IT

В Киеве прошло мероприятие с загадочным названием «ALL OVER ANTIRISK IT» УСТОЙЧИВЫЕ СИСТЕМЫ И РИСКИ: ТРЕБОВАНИЯ. ОГРАНИЧЕНИЯ. ПРОБЛЕМЫ.
За замысловатым названием кроется тематическая конференция, посвященная вопросам обеспечения непрерывности бизнеса.
Вопросы обеспечения непрерывности бизнеса на текущий момент очень популярны для украинских компаний. Особо острый интерес проявляется в банковской и околобанковской сфере, а также в ритейле. По этой причине народ пошел на мероприятие достаточно охотно и вопреки поостывшему интересу к конференциями (даже бесплатным и с фуршетом), которые проводятся чуть ли не каждую неделю прижатыми кризисом интеграторами и вендорами. Почтил своим вниманием мероприятие и Национальный Банк.

Ваш покорный слуга делал  вводный мини-семинар (даже скорее микро-семинар), на тему "что такое BCP и зачем оно нужно?",  модерировал круглый стол, посвященный вопросам "все что вы хотели знать про BCP, но боялись спросить", а также сделал небольшой доклад на тему "как составить эффективный SLA".  Материалы для последнего готовил, мой коллега - Алексей Назаренков, который по объективным причинам не смог присутствовать, но успел заблаговременно поделиться прекрасным материалом. За что ему отдельное спасибо.
За сим выкладываю презентации.



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

понедельник, 8 ноября 2010 г.

Кто последний за банковской тайной?

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

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

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

суббота, 6 ноября 2010 г.

Кража личности как пандемия массового психоза

Интернет пестрит душещипательными заголовками. "Интернет-пользователям грозит новый вид мошенничества – кража личности", "Кража личности – новый вид сетевого преступления" - пугают нас журналисты, плохо понимающие о чем пишут, но здорово подхватывающие темы, которые потенциально поднимут посещаемость их желтых интернет изданий. Приводятся устрашающие цифры потерь и страшная статистика, которой охотно делятся консультанты  и поставщики решений по информационной безопасности. Плевать, что статистика притянута за уши. О происхождении цифр "статистики" просто помолчим. Главное - НОВАЯ УГРОЗА!

Попробуем разобраться в новой интернет-угрозе. Для начала "новая".  Обратимся к википедии:
Кража личности (англ. Identity theft) — преступление, при котором незаконно используются персональные данные человека для получения материальной выгоды. Термин появился в 1964 и является неточным, так как саму личность украсть невозможно. 
1964 год. В космическом смысле прошел действительно очень короткий промежуток времени и угрозу можно назвать новой. Интернет-угрозой назвать тяжелее, ведь интернет появился только через 5 лет, а социальные сети, которые являются корнем всех зол источником угрозы, через 31 год! Все новое - это хорошо забытое старое. В то время преступления базировались на краже и использовании чужих номеров социального страхования. Теперь же собирают данные из социальных сетей. 

Что же делать? Ответ на данный вопрос очевиден - завернуться в простыню и медленно, чтобы не создавать паники, ползти на кладбище.  с умом использовать социальные сети и не раскрывать душу первому попавшемуся боту.

вторник, 2 ноября 2010 г.

Стандарты по управлению информационной безопасностью в банковской системе Украины вступили в силу.

Свершилось! То, о чем так долго говорили большевики на нацбанковских конференциях наконец произошло. Пусть и с опозданием почти на год, Национальный банк Украины принял два стандарта:
  • СОУ Н НБУ 65.1 СУІБ 1.0:2010 “Методи захисту в банківській діяльності. Система управління інформаційною безпекою. Вимоги” (ISO/IES 27001:2005, МОD)
  • СОУ Н НБУ 65.1 СУІБ 2.0:2010 “Методи захисту в банківській діяльності. Звід правил для управління інформаційною безпекою” (ISO/IES 27002:2005, МОD)
По своей сути, как не трудно догадаться из названия, это локализированные версии ISO/IES 27001:2005 и ISO/IES 27002:2005
Стандарты вступаю в силу со дня опубликования постановления (№ 474 от 28 октября 2010 г.).
Банки должны привести  системы управления информационной безопасностью в соответствие с требованиями стандарта до 01.10.2011г.
Также Национальный банк грозится в течение 90 дней осчастливить банки:
  • методическими рекомендациями касательно внедрения стандартов
  • рекомендации касательно перечня, содержания и правил заполнения документов, которые должны быть созданы во время внедрения стандартов
  • рекомендации касательно методик оценки рисков, связанных с информационными технологиями
Срок на внедрения, мягко скажем, оптимистичный. На текущий момент не все банки Украины могут похвастаться выделенной функцией информационной безопасности (помимо администратора защиты информации, который занимается сугубо ключами, как требует 112 постановление). Про функцию внутреннего аудита ИТ лучше просто помолчать. Да и нет сейчас на рынке столько готовых специалистов по аудиту, вздумай банки в срочном порядке ими обзавестись. В общем, прогноз на 01.10.2011 скептический. Но начало положено. Будем радоваться малому в ожидании большого.

пятница, 29 октября 2010 г.

Безопасность без границ

Именно так называется глобальное исследование по информационной безопасности компании Ernst & Young за 2010 год. По названию не трудно догадаться что, ключевые результаты и наблюдения посвящены "размытию" границ предприятия и технологиям, которые этому способствуют - "облачным" вычислениям, мобильным устройствам и социальным сетям.

Что осталось "за кадром".

В приведенных результатах просматриваются еще две интересные тенденции, которые не попали в отчет:
  • Осведомленность пользователей в вопросах информационной безопасности, а точнее ее отсутствие, признано проблемой №1 большинством компаний. Соответственно, повышение осведомленности попало приоритетные задачи ИБ на следующий год
  • Также заметен повышенный интерес к вопросам обеспечения непрерывности деятельности. Кстати, этот тренд очень характерен и для Украины. В одних только банках количество проектов по обеспечению непрерывности бизнеса бьет все рекорды. На то есть целый ряд причин - влияние Базель 2, которые банки активно внедряют, переосознание в период кризиса необходимости обеспечения непрерывности,  ну и самое главное НБУ снял запрет на использование средств на ИТ и консалтинг.

Текст отчета ниже. Детальные результаты выложу позже. Равно как и аналитику для Украины.

вторник, 19 октября 2010 г.

Ее аршином не измерить...

Hаша служба
И опасна, и трудна,
И на первый взгляд
Как будто не видна.
Не видна она как будто на второй.
И на третий тоже...

Финансовый кризис заставил многие компании задуматься над пользой информационной безопасности. Те компании, у которых функции ИБ не было, получили по лбу и начали создавать такую функцию. Те же, кто уже имел ИБ, задумались над ее эффективностью. И пошла мода на ее (еффективности) оценку ...
Консультанты тут же оживились и начали наперебой предлагать кто ROSI, кто разработку KPI.  И неважно, что специалисты по информационной безопасности при упоминании "дисконтирования денежных потоков" восклицают: "кто здесь ?"  не понимают о чем речь. Не важно, что KPI разрабатываются для процессов, которым до достижения хотя бы третьего уровня зрелости (кто не помнит, согласно СММ,  процесс формализован, и мы можем идентифицировать результат его работы) еще как до неба раком очень далеко.
Отдельная песня о том, какие KPI выбираются в качестве показателей эффективности работы ИБ. И как внедрение KPI влияет на поведение сотрудников безопасности. Известный факт - люди себя ведут по-разному в зависимости от того, как вы людей оцениваете.
Возьмем пару примеров из жизни. Не из ИБ, но из ИТ. Просто для наглядности. Есть некая компания, финансовая служба которой обеспокоена постоянно раздутым бюджетом ИТ. На столько, что готова потратиться на внешних консультантов, чтобы докопаться до истины. Консультанты анализируют бюджеты за несколько лет и выявляют странную тенденцию - каждый год раздутый бюджет ИТ недовыполняется. На лицо ежегодная экономия бюджета. А почему же ИТ менеджер его так раздувает?. Все банально просто - читаем его должностные обязанности и видим, что единственный показатель, влияющий на бонус ИТ-менеджера ... экономия бюджета.
Берем пример из жизни ИБ. Начальник ИБ, не мудрствуя лукаво, определяет основным показателем работы ИБ проверенный временем показатель - количество выявленных инцидентов. Ведь не секрет, что в ИБ много выходцев из силовых структур. А процент раскрываемости преступлений остался в крови... Что же может дать такой показатель для бизнеса? Как трактовать результаты? Много выявленных инцидентов - это хорошо? Или это значит, что ИБ работает плохо, раз они происходят? А если их (инцидентов) мало (или вообще нет)? Значит хорошо работает ИБ? Или просто не обнаруживает инциденты? А если к показателю привязаны бонусы? Устоит ли безопасник перед искушением "помочь" показателю в нужную сторону?

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

понедельник, 18 октября 2010 г.

Мониторинг событий на вооружении у финансового аудита

Давно собирался расширить тематику блога "аудитом ИТ" и заодно "ИТ в аудите". 

Неделю назад в Ялте прошла очередная (восьмая) конференция стран СНГ "Аудит и контроллинг в банках". Практически вся конференция была посвящена повышению эффективности работы службы внутреннего аудита. Много говорили о методиках оценки рисков, как инструменте повышения эффективности работы. И очень мало о том, что труд аудиторов пора начинать автоматизировать. Ведь речь идет об аудите не ларьков с носками, где учет ведется в потертой засаленной тетрадке. Не хочется уподобляться Капитану Очевидность, но даже самые отсталые банки уже давно учитывают свои операции в информационных системах. Почему же внутренний аудит до сих пор копается в бумажных документах?  Безусловно, им тоже необходимо уделять внимание, но не все же! И какую уверенность нам даст аудиторская выборка (в среднем 25 операций) на популяции в сотни тысяч и даже миллионы транзакций? Если мы тестируем контроли, что может что-то и даст. Но какова вероятность, что мы выборкой обнаружим мошенническую операцию? Такая же, как встретить динозавра - 50 на 50. А количество мошеннических операций в банках, как показывает несметное число исследований, растет со страшной скоростью.
Если мы используем ИТ для автоматизации учета, почему мы не используем его для автоматизации аудита? Идея совсем свежая - появилась всего лишь в 60-х годах прошлого века. И успешно игнорируется у нас по сей день.
Подходы те же, что и при постанове мониторинга событий информационной безопасности. Мониторим все транзакции, если попадают по определенные условия - генерируется событие, которое уходит на расследование в аудит. По количеству условий и тестов мы ограничены только своей фантазией - от банальных проверок превышения лимита, авторизации операций "не теми" сотрудниками, до сложных перекрестных проверок по нескольким системам.
Те же подходы, которые используются в системах обнаружения аномалий в сетях или при обнаружении карточного фрода, можно использовать для автоматического выявления новых рисковых областей. Например, берем усредненные показатели за период, сравниваем с предыдущими  - если сачок или проседание - задаемся вопросом что случилось. Слишком утрированно, но смысл такой. Или проверяем соответствие закону Бенфорда (там где это применимо естественно). Отклонение - выбрали то, что выделяется, посмотрели более детально.

Материалы моего выступления на данную тему:

четверг, 16 сентября 2010 г.

Модель зрелости процессов защиты персональных данных от AICPA/CICA

American Institute of Certified Public Accountants (AICPA) совместно с Canadian Institute of Chartered Accountants (CICA) опубликовали для комментирования черновик модели зрелости для процессов защиты персональных данных (Privacy Maturity Model). Модель базируется на  Generally Accepted Privacy Principles (GAPP).
Свои комментарии и пожелания можно выразить до первого октября. Инструкции как это сделать тут.

вторник, 14 сентября 2010 г.

В ДТП под Харьковом погибли представители "Бакотек" и McAfee

Сегодня новость грустная. Точнее сказать печальная.

Ночью на трассе под Харьковом в результате ДТП погибли коллеги из McAfee и БАКОТЕК.
Среди погибших:
  • Доминик Сумовски (Dominik Sumowski) -  менеджер по работе с партнерами McAfee в Восточной Европе
  • Константин Здыбель - начальник отдела технической поддержки проектов  БАКОТЕК
  • Витольд Мазанек (Witold Mazanek) - технический эксперт компании McAfee
  • Ольга Журавлева - руководитель отдела по работе с корпоративными клиентами БАКОТЕК

Елена Утвенко, менеджер по развитию бизнеса McAfee, Оксана Лучко менеджер по маркетингу БАКОТЕК, Максим Козуб - переводчик - находятся в больнице. Елена и Оксана в тяжелом состоянии.

Искренние соболезнования

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

среда, 8 сентября 2010 г.

О темной стороне криптографии


    Сисадмин спросил Инь Фу Во:
    – Правда ли, что любой шифр можно сломать?
    Учитель ответил:
    – Можно. Но не "шифр", а систему из четырёх: алгоритм, реализация, окружение и оператор.
    Сисадмин ещё спросил:
    – А что из этих четырёх самое непрочное?
    – Стыки между ними, – ответил Учитель.

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

Истории из жизни:
  1. После очередной утечки информации руководство принимает решение об обязательном шифровании. Вопрос выбора системы простой - спросили у безопасника. Тот почесал затылок и сказал: "ну, давайте использовать PGP - она надежная". Прописали в политику - всем все шифровать с использованием PGP - и почту и диски. А процедуры прописать забыли. Послушные сотрудники все зашифровали. Через какое-то время уходит один сотрудник из компании, потом другой. Обычная текучка - ничего сверхъестественного. А процесса отбирания ресурсов у увольняющихся сотрудников тоже нет. Через время этих сотрудников уже не найти, зато понадобились документы с их рабочих станций. А документы надежно защищены (PGP- диском). Пароля не знает никто - это же конфиденциальная информация. В финале, утеря информации в результате ее шифрования нанесла больше ущерб, чем утечки.
  2. Решила другая компания защищать свои ресурсы от утечек (что поделать, время такое). Разослали приказ - все все шифровать. Но централизованно ничего не внедряли - приказ дан, исполняйте, чего не понятного? Начинает каждое подразделение что-то свое покупать и внедрять. В результате обмен ключами и паролями занимает треть всего документооборота,  затраты на покупку всех систем для компании и на поддержание работы этого зоопарка вызывают приступы у финансов. Да, я говорил, что классификации информации никто не проводил? Поэтому зашифровали все - так надежнее. И не ясно - на сколько сократили потенциальные риски, но явно увеличили расходы на безопасность.


понедельник, 6 сентября 2010 г.

Облака, белогривые лошадки...

ISACA провела web-based семинар, посвященный информационной безопасности и безопасности персональных данных при использовании облачных вычислений.
Материалы в основном базировались на ноябрьской  публикации ENISA (Eropean Network and Information Security Agency), посвященной вопросам безопасности при использовании облачных вычислений.
В документе приводятся выгоды (для безопасности) от использования облачных вычислений, основные риски (для нее же) и рекомендации что с эти всем делать.
Основные риски, приведенные в публикации:
  • Утрата конроля. При использовании облачных вычислений, клиенты неизбежно передают контроль за средой провайдеру услуги. Разумеется это - большой риск для безопасности, ибо провайдер может и не организовать у себя все необходимые меры защиты.
  • Закрытость систем.   На текущий момент мигрировать с одного провайдера на  другого или перевести данные назад в собственную систему - задача не тривиальная, часто не реализуемая. Причем  тут безопасность? - Вопросы доступности информации.
  • Нарушение изоляции (isolation failure). Мда, на русском не звучит. В общем, это класс рисков связанных с нарушением механизма изоляции хранения, памяти, маршрутизации и даже репутации между различными владельцами (так называемая guest-hoping атака). Если на пальцах, то зловредные действия у одного владельца в облаке наносят ущерб репутации другому. В результате риски утечки информации, ущерба репутации или нарушения сервиса для сервис-провайдера и его клиентов.
  • Комплайенс-риски. Опять по-русски нормально не переводится, но все уже к слову комплайенс привыкли.  В общем, кто не привык - это риски не соответствия каким-либо требованиям.  Например, проинвестировала компания в получение сертификата по информационной безопасности, например ISO 27001... мда, редкое явление PCI DSS. А потом с какого-то перепугу перенесла часть данных в облако. 
  •  Компрометация административного интерфейса. Интерфейс, с помощью которого  "облачный провайдер" управляет своими ресурсами, доступен через интернет. И получить через него доступ можно к огромному количеству данных от самых разных компаний. А постоянно появляющиеся уязвимости браузеров только усугубляют риск.
  • Защита данных. Вот уж неожиданный риск. Честно говоря, не представляю, что авторов сподвигло выделить этот риск как отдельный класс, но к нему можно свести все остальные. Ибо проблема защиты возникает как при передаче данных в облако, так и при хранении, так и при уничтожении и т.д.
  •  Небезопасное / неполное уничтожение данных. Обеспечить полное уничтожение данных без возможности их восстановить - достаточно хлопотное мероприятие для информационной безопасности. Например, в Нацбанке использование электро-магнитного импульса (вроде того, что создает "Лавина") для уничтожения данных на жестких дисках первый отдел не считает безопасным. Приходится брать старую добрую дрель и делать из дисков дуршлаг... В облаке же, где трудно понять вообще где что физически хранится, организация безопасного и полного уничтожения данных по запросу клиента кажется сизифовым трудом.
  • Внутренний злоумышленник. Ну, тут все просто - та же проблема, как и везде, только возможностей у него не в пример больше, т.к. доступ есть к данным сразу многих компаний.
 И это только основные риски.

Какой же выход из данной ситуации? Как говорит народная мудрость: "даже если тебя съели, у тебя остается еще два выхода" Выходов как минимум два:
  1.  можно использовать традиционный метод кнута - вводим очередную обязательную сертификацию, какой-нибудь CPSS (Cloud Provider Security Standard) и понеслась....
  2. Можно конечно и пряничный метод - провайдеры сами заказывают аудит по ISAE 3402 Assurance Reports on Controls at a Service Organization. Добровольно прошли, опубликовали отчет, показали что безопасность есть, завлекаем этим клиентов.
При любом подходе результат одинаков: деньги - консультантам, расходы - провайдерам, счастье безопасность - потребителям.



    пятница, 27 августа 2010 г.

    О социальных сетях, закручивании гаек и осведомленности

    Как и ожидалось, после обвинения социальных сетей в том, что они являются источником  утечки информации, особенно персональных данных, и началом крестового похода против них в виде закручивания гаек и запрещения использования подобных ресурсов, последовала адекватная реакция.
    В ход пошло все. Пригодились и проверенных временем варианты обходов файерволов типа:
    • использования анонимайзеров 
    • "договорился с администратором - он человек добрый, разрешил"
    • принес свой модем (слава богу 3G модем не больше флешки - легко и удобно), воткнул в рабочий комп и "все равно буду пользоваться"
    И пользователю по барабану, что создают огромные дыры в защите компании. По большому счету они об этом даже не задумываются.

    Появились и инструменты автоматизации нелегальной передачи данных через социальные сети. Например, добрые дяди из  Технологического института Джорджии (США) разработали инструмент под названием Collage, который позволяет интернет-диссидентам вставлять скрытые с использованием стеганографии сообщения в Twitter-посты и Flickr-фотографии, чтобы обойти цензуру и обмануть "репрессивные правительства". Да здравствует демократия!
    Стеганография не подходит для чатов? Пожалуйста - вот вам "Код 9" - простая система условных сигналов, что над тобой кто-то стоит и контролирует переписку и нужно сменить тему.
    Короче повторяется та же ситуация что и с другими контролями.  Ввели 28-символьные пароли, которые обязательно должны включать символы английского, русского и иврита, а также цифры и минимум 5 спецсимволов, а также должны меняться каждую неделю? А мы их на стикер запишем и приклеим к монитору!
    Разделили права в системе на выполняющего и проверяющего? А мы паролями обменяемся!
    Карточный доступ в компанию с фиксацией времени кто когда ушел/ пришел? Сосед придет пораньше с моей карточкой отметиться, а я вечером с его, ибо он ушел пораньше!
    Нет прав на установку софта? Принесем pоrtable версию!
    При этом повышение осведомленности пользователей, объяснения почему вводятся нет или иные ограничения чем чревато для компании не соблюдение тех или иных правил считается излишним баловством: "все люди взрослые - должны понимать..."
    Как результат, каждое "техническое" усиление безопасности в реальности приводит к появлению еще более серьезных уязвимостей и проблем с безопасностью.  

    пятница, 13 августа 2010 г.

    Google опять рассылает спам

    Получил сегодня от знакомой письмо (с гугловского ящика на гугловский). Приглашает меня присоеденится к очередной социальной сети.
    По старой привычке переспросил что, да зачем. Знакомая говорит: "Не знаю. Ничего не посылала".
    Посмотрел детали письма - таки да не отправляла.
    Все-таки социальные сети сильно упрощают сбор адресов и сценарии с впариванием всякой ерунды якобы от знакомых к их конактам. Достаточно лишь посмотреть в публичном профайле кто с кем знаком.

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

    понедельник, 9 августа 2010 г.

    CISO <> менеджер по безопасности <> специалист по безопасности

    Почитал в прошлый четверг отзыв о 4-м собрании украинской группы информационных безопасников. Наводит на мысли...
    Человек имеет за плечами ИТ образование и много лет занимался борьбой с фродом в банках - деятельность очень близкая по духу и подходам к информационной безопасности. И при этом пишет: "я чувствовал себя "глухим" на 60% докладов". Можно конечно объяснить сей факт обилием глубоких технических деталей, которыми изобиловали дискуссии...
    Но, если посмотреть шире, вот также большинство безопасников пытается объясняться с бизнесом. И бизнес также остается глух - услышал много непонятных технических терминов, не понял, не понял на сколько критично, решил, что скорее всего что нет, выбросил из головы. С одной лишь небольшой разницей - потом не дает денег на инициативы.
    И вроде уже все осознали, что есть техники, позволяющие говорить с бизнесом на "языке денег" - оценка рисков, выраженная в деньгах, кто-то  ROSI вспоминает...
    И тут становятся глухими безопасники. Базового понимания финансов, хотя бы на уровне тренинга "финансы для нефинансовых менеджеров" у большинства специалистов по безопасности нет. Вот и пойди поговори с бизнесом на его языке... Ты ему про уязвимости и DOS-атаки, мол страшно это, давайте бюджет - будем закрывать. А он в ответ:  "каково от этого влияние на EBT?" И специалист по безопасности поджав хвост отступает. И пока для такого специалиста EBITDA - это неприличное ругательство - его потолок профессионального развития мененджер по техническим вопросам с совещательным голосом. А бюджет будет завистеть от:
    1. настроения начальника
    2. рекомендаций внешних консультантов (если они были убедительны)

    понедельник, 2 августа 2010 г.

    4-е собрание Ukrainian Information Security Group

    В пятницу был на мероприятии. Прошло на редкость организованно и живо. Мелкие организационные проколы вроде не сразу заработавшего микрофона или отсутствие презентера утонули в массе положительных вещей.
    Отдельно хочется отметить модерирование мероприятия. Немногочисленные попытки чрезмерного комментирования выступлений и дискуссии не по теме вежливо и беспощадно подавлялись, возвращая особо горячих в конструктивное русло.
    Большая часть мероприятия была посвящена разнообразным формальным и неформальным объединениям специалистов по безопасности. Народ "дозрел" до создания своего формального сообщества.  Правда пока еще существует много противоположных мнений по форме и деятельности такого сообщества, но первые шаги уже сделаны. В ближайшее время на группе UISG будет обсуждаться вторая версия (первая обсуждалась инициативной группой чуть ранее) устава организации. Ждем горячих прений в ближайшие пару месяцев.
    Я, по просьбе организаторов, повторил доклад, посвященный персональным данным, который я уже делал на Legalcamp 2.0 , но немного в сокращенной форме.
    Мой коллега, Андрей Лысюк, который по совместительству является координатором по сертификации украинского чаптера ISACA, рассказал немного о самой организации, а также о сертификатах в области информационной безопасности, процессе их получения, тонкостям и хитростям процесса получения и т.д. Не смотря на то, что тема глубоко не новая, она была воспринята с большим интересом. Поскольку всегда интереснее послушать выжимку с полезным материалом, чем блуждать по различным сайтам и форумам, собирая данную информацию по частям. Публикую материалы его доклада:


    Полный отчет о мероприятии можно почитать тут

    вторник, 29 июня 2010 г.

    Закон о защите персональных данных подписан президентом

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

    понедельник, 14 июня 2010 г.

    Первые жертвы закона о персональных данных

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

    Сайт Украинской Хельсинской группы по правам человека в пятницу обнародовал приказ управления образования Святошинской района в городе Киеве государственной администрации «О назначении ответственных по предоставлению информации», по которому педагоги должны информировать власти обо всех общественно-политических мероприятиях в их учреждениях.

    Приказ издан на основании поручения Киевского мэра от 2 апреля 2010 года № 30341 относительно "усиления внимания руководства администрации президента Украины к информации, которая касается городской власти, повышения качества информационно-аналитических материалов о общественно-политических и резонансных событиях в городе и районах, в частности предоставлении ежедневной оперативной информации о событиях в районе".

    Администрация президента уже успела открестится от причастности к данному приказу, назвав его "неумная и никому не нужная самодеятельность". "Заявляем, что Администрация президента Украины не давала никаких поручений - ни письменных, ни устных - о сборе любой информации о общественно-политических мероприятиях в образовательных или любых других заведениях города Киева", - сказано в сообщении.

    Ситуация выглядит абсурдной. Вспоминается народная мудрость - инициативный дурак - хуже вредителя. Но с другой стороны, cхожесть ситуаций с Россией наталкивает на глупые мысли: "А может старик Зейгетс не такой уже и фантазер, и будущее, описанное в "Духе времени" не такое уже и далекое?"

    пятница, 11 июня 2010 г.

    О понятиях

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

    Пример номер раз. Человек привык понимать какой-то термин только в этом значении и ему даже в голову не приходит, что кто-то его может воспринимать по-другому.
    Случай из жизни. Крым, Воронцовский парк. Экскурсовод водит группу иностранцев, рассказывая о растениях, произрастающих в парке: как называется, откуда завезено и т.д. Один из туристов, указывая на незнакомый ему дерево/куст  задает вопрос: "а это что ?". Экскурсовод, пожимая плечами, флегматично отвечает: "Самшит". Для него этот куст не представляет особого интереса - растет по всему Крыму, ничего примечательного. Но вот незадача. Туристы, изначально англоговорящие, слышат для себя: "Some shit". В общем, неудобно получилось.
    Причем тут спрашивается информационная безопасность? Другой пример. Проект по классификации информационных ресурсов. Провелась инвентаризация информации и назначаются ее бизнес владельцы. И тут начинается хаос. Представители бизнес подразделений, под любым предлогом отказываются встречаться с рабочей группой и всячески саботируют процесс. После анализа причин выявляется, что никто в начале проекта не удосужился донести в чем состоит ответственность бизнес владельца ресурса. Соответственно, следуя человеческой природе, начинаются самые мрачные предположения и додумывания. Бизнес владелец вырисовывается ответственным за все нарушения связанные с активом, да еще и материально ответственным. Никому такое счастье не нужно.

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

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

    четверг, 10 июня 2010 г.

    Комментарий к обзору методик управления рисками

    Сегодня обратил внимание, что в обзоре методик управления рисками  допущена неточность. В таблице указано, что методика MEHARI платная. На самом деле последняя версия (инструментария) уже распотраняется по GNU лицензии. Каюсь.

    В качестве компенсации выкладываю дополнительные данные про методику.
    Итак, полное название методики MEHARI: RISK ANALYSIS METHOD (не путать с MESARI, методику управления рисками  Credit Agricole)
    Разработчик CLUSIF 
    Стадарт разработан в 1996 году,последняя версия от 2007.
    Методика детально рассматривает только оценку рисков, без деталей по всему процессу управления рисками.
    Официальный сайт https://www.clusif.asso.fr/en/clusif/present/
    Документация доступна в свободном доступе, инструментарий (в Excel) распостранятся GNU лицензии. Для скачивания необходимо ознакомится с условиями распостранения и зарегистрироваться.

    По мере сил буду выкладывать детальные обзоры по другим методикам.

    quoth I

    вторник, 8 июня 2010 г.

    NIST обновил стандарт по обеспечению непрерывности работы для федеральных информационных систем

    Вчера национальный институт стандартов США выпустил новую редакцию Contingency Planning Guide for Federal Information Systems.

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

    1. Разработать политику по планированию обеспечения непрерывности работы информационных систем. Формальная политика, определяющая полномочия и методологические принципы, необходимые для разработки эффективного плана обеспечения непрерывности работы информационных систем.
    2. Выполнить анализ влияния на бизнес (business impact analysis). Анализ влияния на бизнес помогает идентифицировать и приоритезировать критичные для поддержания бизнес функций организации информационные системы и из компоненты. Шаблон для проведения  анализ влияния на бизнес прилагается.  
    3. Определить превентивные контроли. Меры, предпринятые для снижения эффекта от сбоев в системе, могут повысить доступность систем и снизить стоимость жизненного цикла обеспечения непрерывности работы.
    4. Выработать стратегию по обеспечению непрерывности работы информационных систем. Разработанная стратегия обеспечивает быстрое и эффективное восстановление систем после сбоя.
    5. Разработать план обеспечения непрерывности работы информационных систем. План должен содержать подробное руководство и процедуры по восстановлению затронутых сбоем систем и однозначно определять уровень влияния системы на безопасность и требования по восстановлению.
    6. Обеспечить тестирование плана и обучение персонала. Тестирование проверяет способность к восстановлению, поскольку обучение персонала и выполнение учений по восстановлению позволяет идентифицировать недостатки плана, а также меры, которые необходимо предпринять по улучшению плана для повышения его эффективности.
    7. Обеспечить поддержание плана в адекватном состоянии. План должен быть "живым" документом, который регулярно обновляется с учетом  организационных изменений и изменений в системах.

    Документ также предлагает три формата для разработки плана по обеспечению непрерывности работы ИТ систем в зависимости от низкого, среднего или высокого уровня влияния (определено в Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems.)

    С полным текстом можно ознакомится на сайте NIST Special Publication 800-34 Rev. 1

    понедельник, 7 июня 2010 г.

    Социальные сети - серьезная угроза компании?

    Последний год все больше и больше нагнетается обстановка вокруг социальных сетей. Компании обвиняют социальные сети во всех смертных грехах, начиная от "воровства" времени сотрудников и заканчивая утечками секретной информации. Бдительные администраторы денно и ночно пополняют списки запрещенных к посещению сайтов, а также сайтов-анонимайзеров, через которые ущемленные пользователи продолжают пробиваться в вожделенные социальные сети.
    Но следует ли так рьяно продолжать борьбу? Какую пользу в конечном итоге получат компании?
    Закручивание гаек не заставит работников больше времени работать, а только понизит мотивацию. Сотрудники все равно найдут себе другое занятие - курение, чаепитие, читание новостей, занятие йогой. Человек не может как робот отрабатывать за компьютером 8 и более часов подряд. Ему необходимо на что-то переключаться, сбрасывать накопившиеся эмоции.
    Опять же есть бизнес-ориентированные сети, типа linkedin в которых можно выйти на нужный контакт, получить полезную информацию по бизнесу.
    Теперь собственно об утечках. Безусловно их количество с каждым днем растет. Многие помнят утечку документации на борт номер 1, которую нерадивый сотрудник случайно выложил в сеть, перепутав файлы. Или утечку информации о секретных разработках Microsoft, когда сотрудник Microsoft, участвующий в проекте похвастался об этом в своем профайле.
     Но виноваты ли в этом социальные сети? А может проблема совсем не в сетях? Что до появления социальных сетей мешало сотрудникам "делится" секретной информацией в беседе с друзьями, родственниками, да и просто знакомыми?
    Может, вместо того, что бы бороться с революцией, ее следует возглавить? Как, например, это сделала компания Intel в своих правилах использования социальных сетей в корпорации Intel.

    среда, 2 июня 2010 г.

    Рада приняла закон о защите персональных данных

    Вчера Верховная рада приняла закон № 2273 "О защите персональных данных". Закон вступает в силу с 1-го января 2011.
    С текстом можно ознакомится тут.
    Первая попытка принятия закона в 2006 закончилась ничем - президент наложил вето по причине несоответствия закона с конвенцией Совета Европы о защите личности.
    Новая редакция была переработана, хотя некоторые моменты остались не покрыты. Например, нис лова не сказано о том, должен ли владелец базы персональных даных сообщать об утечках персональных данных субъекту персональных данных.
    Некоторые формулировки откровенно режут слух. Чего стоит один только "володілець".

    Но, как говориться, первым блин комом. Теперь не будем выделяться на фоне Европы.
    Теперь ждем более детальной законодательной базы и поправок.
    С почином...

    вторник, 1 июня 2010 г.

    2:0 Не в пользу Нацбанка

    1-е июня. Начало лета, отпусков, жары, лета, моря, пляжа. И конец иллюзиям банковских безопасников получить стандарты регулирующие вопросы информационной безопасности  раньше осени.
    Национальный банк в очередной раз не сдержал своих обещаний по введению стандартов. На сей раз до конца мая.
    Ситуация с регулированием вопроса информационной безопасности в банках Украины продолжает оставаться парадоксальной.
    С одной стороны, выпуск новой редакции постановления "Об операционной деятельности" снял с банков те минимальные требования по информационной безопасности, которые были в старом, 243-м постановлении.
    Тоже достаточно парадоксальная история - при пересмотре постановления "потеряли" раздел, посвященный требованиям к системам автоматизации банка. А когда спохватились, было уже поздно - постановление уже приняли. С другой стороны вроде не беда - Национальный банк разработал два отраслевых стандарта - ГСТУ СУІБ 1.0/ISO/IEC 27001:2010 «Iнформаційні технології Методи захисту Система управління інформаційною безпекою Вимоги» и ГСТУ СУІБ 2.0/ISO/IEC 27002:2010 «Інформаційні технології  Методи захисту Звід правил для управління інформаційною безпекою». Еще на анонсе проекта стандарта в феврале стало понятно, что стандарт "сыроват".
    Термины противоречивы, практическая реализация некоторых требований весьма туманна даже для авторов.
    Тем не менее было выдано бодрое обещание утвердить стандарты до конца марта и начинать требовать соответствия с 1-го января 2011. И не важно, что времени не достаточно, что на рынке нет достаточного количества специалистов, чтобы решать новопоставленные задачи, что не закладывались бюджеты. Главное начать.
    И вот проходим март и... Ничего. Национальный банк собирает новую конференцию, посвященную стандарту и называет новый срок - конец мая.
    Итак 1-е июня.Стандарты так и не приняты, вероятность того, что к ним кто-нибудь вернется до осени стремится к нулю.
    Ждем осени.

    четверг, 20 мая 2010 г.

    День банковских работников Украины


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

    среда, 19 мая 2010 г.

    Новые правила по охране труда при работе с компьютером

    5 мая Государственный комитет Украины по промышленной безопасности, охране труда и горному надзору (Госгорпромнадзор) утвердил "Правила охраны труда во время эксплуатации электронно-вычислительных машин" (приказ N65).

    Правила распространяются на всех субъектов ведения хозяйства независимо от форм собственности. Они устанавливают требования:
    •     к производственным помещениям
    •     электробезопасности во время эксплуатации
    •     к рабочему месту оператора
    Какими же новшествами порадуют нас новые правила?

    "Організація робочого місця оператора повинна забезпечувати відповідність усіх елементів робочого місця та їх розташування ергономічним вимогам ГОСТ 12.2.032-78 "ССБТ. Рабочее место при выполнении работ сидя. Общие эргономические требования"."
    Свежо. Автор стандарта, не мудрствуя лукаво, использовал проверенные временем требования, изложенные более 30 лет назад.

    "Під матричні принтери потрібно підкладати вібраційні килимки для гасіння вібрації та шуму."
    Продавцы вибрационных ковриков, готовьте карманы - сейчас все прибегут покупать ваш бесценный товар!

    "Щоденно перед початком роботи необхідно проводити очищення екрану відеотерміналу від пилу та інших забруднень."
    Ну хоть одна приятная новость! Будем, как в старые добрые времена, закупать спирт для протирки...тонким слоем...

     А если серьезно - плакать хочется. Новые правила отличаются от старых (99-го года)  только длинной текста, причем в меньшую сторону. Выброшены формулировки про "ЕОМ типу СМ та ЕС" (эх, мой первый компьютер - ЕС1840, кто помнит - поймет), санитарный врач СССР в тексте заменен санитарным врачом Украины, выброшены требования к мониторам по радиоактивному излучению - вот и все правки. Автор умудрился выбросить даже такой раздел как "Ответственность".

    Что же, зато нас никто не обвинит в плагиате. Не передрали "западные стандарты" (ведь их нужно переводить), а используем свое, родное, проверенное не одним десятком лет.

    воскресенье, 9 мая 2010 г.

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

    Inforamtion Risk Management Methodologies Review
    View more presentations from Vladimir Matviychuk.

    В колонках 2-9 цифрами отмечен уровень покрытия методикой конкретного раздела управления рисками:
    1 - поверхностно -> 3- максимально детально
    "-" - не рассматривается данной методикой

    В колонке "необходимые навыки" цифры обозначают уровень подготовки, которым должен обладать специалист для применения методики:
    1- минимальная подготовка -> 3- требуется серьезная подготовка

    вторник, 4 мая 2010 г.

    Закон о персональных данных. Когда?

    В прошлом году купил автогражданку. С выбором страховой особо не заморачивался - пользы от нее все равно нет, но обязательная, а потому - надо. Обратился в ближайшую страховую, которая подвернулась на пути - "Княжу".
    Сегодня мне позвонил юбилейный, 10-й (за последние две недели) страховщик, который, как и друге подобные, раздобыл себе их базу. Как и предыдущие девять, страховщих отрабатывал стандарную схему "на дурака":"-Здравствуйте, это имя_отчество? У Вас машина марка_такая-то? У Вас заканчивается обязательная страховка и Вы до сих пор не заплатили. Оставайтесь на месте, мы уже едем - готовьте деньги."
    Вобщем, пошли они туда же, куда и предыдущие, но гложет мысль: "Доколе можно терпеть?"
    Во всех цивилизованных и полуцивилизованных странах закон "о персональных данных"  принят уже несколько лет назад. Нельзя сказать, что пришли к нему чисто и гладко, но есть хоть призрачная иллюзия, что компании, хотя бы из под палки, но как-то будут оберегать твою информацию от спамеров. И это ведь не самый страшный сценарий. Есть же базы и с более интересной информацией на основании которой можно попасть значительно большие неприятности, чем просто спам.
    Глядя на карту Европы, отражающую текущую ситуацию по законодательству о персональных данных (взято из отчета Ernst & Young "Top privacy issues for 2010"), понимаешь, что не ту страну назвали Гондурасом.
    Из всей Европы только Украина, Молдова и Турция не могут принять закон.  При этом, Ураина приняла его в первом чтении, но когда будет второе и будет ли?

    суббота, 17 апреля 2010 г.

    Мое выступление на Международном Банковском "CIO форум" в Ялте

    Выступал вчера на Международном Банковском "CIO форум" в Ялте. Тема "Роль CIO в построении системы управления информационной безопасности банка"

    Материалы тут

    воскресенье, 11 апреля 2010 г.

    Достаточно ли аудита ИТ и ИБ в рамках финансового аудита?

    При общении с руководством различных компаний на вопрос: "Проводится ли у Вас регулярный аудит информационной безопасности?", получаешь ответ: "Конечно - ежегодный внешний аудит".  И в большинстве случаев выясняется, что это были процедуры в рамках аудита финансовой отчетности. При этом руководство компании уверено, что проведенных процедур достаточно, чтобы получить картину о текущем состоянии ИТ и информационной безопасности. Так ли это на самом деле? И вообще, зачем аудиторам смотреть на информационную безопасность и ИТ в рамках финансового аудита?!? Обратим свой взор на  требования международных стандартов аудита (ISA). В частности, стандарт ISA 315 «Изучение предприятия и его окружающей среды и оценка рисков существенного искажения финансовой отчетности» говорит:
    41. Аудитор должен изучить внутренние контроли предприятия, которые относятся к аудиту. (…)
     43. Внутренние контроли согласно данному стандарту состоят из следующих компонентов:
    (a) Контрольная среда.
    (b)  Процесс оценки рисков предприятия.
    (c)  Информационные системы и коммуникации, включая сопутствующие бизнес-процессы, относящиеся к финансовой отчетности.
    (d) Контрольные процедуры.
    (e)  Мониторинг контролей.

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

    понедельник, 5 апреля 2010 г.

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

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