вторник, 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-е июня.Стандарты так и не приняты, вероятность того, что к ним кто-нибудь вернется до осени стремится к нулю.
Ждем осени.