Что включить в политику работы в социальных сетях с точки зрения ИБ?

Многие пользуются социальными сетями (читая эту заметку, вы уже ими пользуетесь). Кто-то в формате "read-only", кто-то активно участвуя в дискуссиях; кто-то трепется с бывшими одноклассниками в "Одноклассниках", а кто-то активно обменивается опытом с коллегами в Facebook; кто-то является членом публичных "ВКонтакте", а кто-то наборот предпочитает закрытые междусобойчики. Все эти ситуации объединяет одно - использование нового канала коммуникации, который несет с собой не только преимущества, но и риски. Причем риски не только типичные для любого Web-сайта и описанные мной ранее, но и риски утечки информации, нарушение этических норм, нарушения прав на интеллектуальную собственность и т.п.

Раз у нас есть риски, то должна быть и политика управления ими. Причем речь идет не о самой простой из них, которая заключается в полном запрете социальных сетей (хотя нашим чиновникам хотят такое запретить на высочайшем уровне - слишком уж много глупостей они пишут). И даже не о той, которая хорошо иллюстрируется приведенной картинкой (спасибо Alex Toparenko) и известной поговоркой "молчание - золото". Речь идет о полноценной политике использования социальных сетей в контексте информационной безопасности.

В целом данная политика должно состоять из 3-х блоков "об общего к частному":

• Общее отношение компании к социальным медиа. Что используется, а что нет; для чего; какие полномочия даны пользователям; будет ли проводиться модерация контента и т.д.?
• Что могут и что не могут сотрудники делать в онлайн-пространстве. При этом данный раздел должен включать в себя не только требования, но и лучшие практики и советы, как вести себя в той или иной ситуации, а также в зависимости от роли - пользователь, как частное лицо, или пользователь, как сотрудник компании. Общим должно быть правило "думай, прежде чем что-то опубликовать в социальной сети". Стоит лишний раз напомнить пользователям, что все, что опубликовано в Интернет, уже врядли может быть оттуда удалено. Поэтому надо взвешивать последствия любого своего действия в социальных сетях; и взвешивать ДО, а не ПОСЛЕ.
• Что могут и что не могут публиковать сотрудники на социальных ресурсах, в которых им разрешено участвовать от имени компании. Очевидно, что врядли работодатель будет рад, если его сотрудники на ресурсах, ассоциированных с компанией, будут поливать грязью действующую власть или выкладывать контент, нарушающий чью-то интеллектуальную собственность (да и от своего собственного имени это не очень-то приветствуется).

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

И не забудьте включить в эту политику раздел о том, кто отвечает за ее реализацию и с какой частотой ее надо пересматривать. В отличие от парольной политики, не меняющейся годами, работа в социальной сети претерпевает изменения достаточно часто. Кто должен быть владельцем данной политики? Вопрос не простой, т.к. работа в социальной сети предполагает затрагивание интересно разных подразделений - PR, маркетинг, HR, юридическое, ИТ, безопасность, работа с клиентами и т.д.

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

• Использование определенных платформ Social Media. Например, работникам может быть разрешен доступ к Facebook, LinkedIn и Twitter, но запрещен к "Одноклассникам" и "ВКонтакте". Это может быть как глобальное правило "для всех", так и гибкая политика доступа для разных групп пользователей, затем реализуемая на межсесетевом экране. При этом можно ограничивать доступ не только к сайту целиком, а к отдельным его разделам или микро-приложениям, которые в нем используются, или применять иные гибкие настройки разграничения доступа. Такие прикладные межсетевые экраны (application firewall или next generation firewall) сейчас есть у некоторых производителей (мы вот тоже имеем такой продукт - Cisco ASA CX).
• Помимо ограничения на конкретные платформы или разделы социальной сети политика может ограничивать доступ и к материалам на определенную тему - от банальных порнография, реклама суицида и наркотиков, до посещения социальных сетей для поиска работы (исключая сотрудников HR) или страниц конкурентов на социальных сетях (исключая сотрудников отделов экономической безопасности или маркетинга).
• Ответственность пользователей за нарушения правил общей политики информационной безопасности. Не мешает лишний раз напомнить, что нет никакой разницы как осуществлена кража и передача конфиденциальной информации - по e-mail, USB или через "Мой Круг" или Google+. Сюда же будет включаться и перечень наказаний за нарушения, например, отлучение от Интернет или иные формы дисциплинарного воздействия, согласуемые с Трудовым Кодексом.
• Пароли и учетные записи. Хорошей практикой является включение в политику требования, чтобы пароли к учетным записям социальных сетей (исключая быть может корпоративные, если реализована единая система Identity Management) не совпадали с паролями, используемыми в корпоративной сети.
• Время и цель доступа в социальные сети. Это вообще-то не функция ИБ, но уж слишком часто навешивают на безопасников контроль действий сотрудников в Интернет, контроль посещаемых сайтов, скачиваемых файлов и т.д. Если и у вас это так, то тогда стоит зафиксировать соответствующие правила. Например, "использование социальных сетей в личных целях в рабочее время запрещено" или "использование социальных сетей в личных целях в рабочее время разрешено в течение 30 минут ежедневно с 9.30 до 10.00 утра и с 17.30 до 18.00 вечера". На межсетевом экране это правило также легко зафиксировать, если межсетевой экран оперирует не IP-адресам в своих правилах, а именами пользователей.
• Контроль контента. Поскольку социальная сеть подразумевает общение по принципу "один ко многим" или "многие к одному", то в отличие от переписки, где главенствует принцип "один к одному", контроль любого контента, размещаемого в социальных сетях от имени компании и с ресурсов, принадлежащих компании, никаких конституционных прав не нарушает. Поэтому в политике должно найти отражение правило, что любой контент может быть проверен сотрудниками с соответствующими привилегиями; обычно это ИБ, юристы и HR. Сюда же могут попасть правила, связанные с регистрацией действий и архивацией контента, связанными с сотрудником, сидящим в социальных сетях. Правда, прописывая условие регистрации и архивации будьте готовы реализовать его на практике, что не просто, т.к. требует немалых вычислительных ресурсов под данную задачу. Что же касается функции DLP для Web-контента, то это также возможно сегодня в некоторых продуктах.
• Вредоносный код и фишинг. В приведенной по ссылке выше презентации описаны различные риски, связанные с открытием ссылок или запуском файлов от посторонних людей. Понятно, что этого делать не надо, но лишний раз напомнить (желательно с примерами скриншотов) не помешает. Это для безопасников очевидно, а для рядовых пользователей ничего не стоит кликнуть на флеш-ролик с "котэ", который в скрытом режиме устанавливает трояна или крадет пароли доступа.
• Интеллектуальная собственность. Запрет на нарушение прав на чужую интеллектуальную собственность очевиден, но... его просто записать, но сложно контролировать на практике. По крайней мере по отношению к мультимедиа-контенту. Поэтому в некоторых случаях проще запретить выкладывание таких файлов или ввести их премодерацию.
• Персональные данные. Также нелишним будет еще раз напомнить про правила работы с персональными данными клиентов, партнеров и иных лиц, которые оставили свои ПДн в социальных сетях, контролируемых компанией. Это если говорить о сотрудниках. Если же у вас есть собственная социальная сеть, то не забудьте опубликовать в ней политику работы с ПДн, выполнив тем самым требование ФЗ-152. Правда, не всегда понятно, как это сделать на чужих социальных ресурсах, на которых у вас всего лишь "страничка".
• Информационные войны. Это нередкость в Интернет-пространстве. Ждать от сотрудников, что они будут уметь воевать, не стоит. Но лишний раз напомнить им, чтобы они не ввязывались в такие войны (троллинг, флейм и т.п.) стоит. Также можно включить рекомендацию сообщать обо всех случаях публикации негатива о компании. Главное, четко определить границы между негативом и шуткой (хотя это непросто). Этот тот случай, когда простого требования недостаточно, - необходимо чуть больше описания, рассмотрение примеров и т.д.

• Спам. У нас на корпоративном блоге российского офиса Cisco нередко появляется спам в комментариях к заметкам. Бороться с ним можно разными методами, которые также должны найти отражение в политике работы с социальными сетями. Это и CAPTCHA, и запрет на публикацию комментов анонимами (так сделано у меня на этом блоге), и использование специализированных движков для контроля спама (так сделано, например, у Алексея Волкова) и т.п., включая и ручной просмотр, если комментариев немного.

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

ЗЫ. Кстати, 1.5 года назад я уже давал ссылку на интересный документ по тому, что включать в политику работы с социальными сетями. Документ по-прежнему актуален.

Подробнее…

Что бывает после инцидента ИБ?

Что бывает после инцидента ИБ?.. Вопрос непраздный и интересный, но мало кто на него может дать универсальный ответ. На первый взгляд все очевидно. Надо извлечь уроки и устранить причины инцидентов. Но это только на первый взгляд. На самом деле статистика немного иная. В 2011-м году Forrester провел опрос около двух с половиной тысяч руководителей ИТ-подразделений и людей, принимающих решения, и задал им простой вопрос: "Если вы сталкивались с инцидентами ИБ, то какие изменения они повлекли за собой за последние 12 месяцев?". Ответы были неожиданными.

С самым распространенным ответом все вроде бы понятно. Впечатляет второй по распространенности ответ - "ничего не поменялось". В трети случаев (по оси абсцисс отложены проценты ответивших) фиксация инцидента не приводила ни к чему! Можно конечно предположить, что инциденты были несерьезные и в процесс их анализа было принято решение не тратить свои усилия на борьбу с ними, но в это верится с трудом. Увеличение затрат на защитные технологии, рост затрат на программу реагирования на инциденты - ответы тоже очевидные.

То, что удар по репутации в результате инцидента возможен - это вещь бесспорная, а вот то, что это происходит в 9% случаев - цифра интересная. Хотя тут было бы интересно посмотреть на то, как респонденты оценивали удар по репутации. Только ли по факту публикации в СМИ или еще какими-то методами пользовались; с привязкой к бизнес-показателям. Число тех, кто решил сменить поставщика продуктов или услуг достаточно велико - тоже интересный результат.

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

Подробнее…

Тихой сапой в деятельности служб ИБ наступает революция

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

• Нежелание пользователей использовать выданную на работе оргтехнику по 4-5 лет. Как раз наоборот - пользователи хотят жить как в обычной жизни - устарел компьютер - поменял, понравилась новая модель смартфона - поменял и т.д. И они это начинают диктовать своему предприятию. На ИБ это влияет несильно, но жизненный цикл средств защиты уменьшается и это надо учитывать при бюджетировании и выработке стратегии тестирования и внедрения средств защиты (нужно ускоряться).
• Концепция BYOD, о которой не только уже все слышали, но и начинают использовать. Одно дело защищать корпоративные устройства и другое дело - личные, на которых может находиться (и находится) личная информация пользователя, его персональные данные, которые он не хотел бы делать достоянием если не гласности, то ИТ/ИБ-службы.
• За BYOD мягкой поступью идет BYOT, т.е. "принеси свою технологию", когда пользователь начинает приносить свои приложения, делающие их работу удобней и эффективней. А это приводит к тому, что стандартизация ПО, о которой так ратуют многие апологеты ИТ, уже не является панацеей. Нет стандарта на используемое ПО - специалистам по ИБ приходится расширять свои знания в части изучения нового софта, новых уязвимостей, новых угроз, новых каналов утечки и т.д. Это требует ресурсов, о выделении которых надо думать заранее.
• Размывание границы между личным и корпоративным не только в устройствах или технологиях, но и в действиях, которые пользователи осуществляют в рабочее время с личных устройств или с корпоративных устройств в нерабочее время. Не зря в развитых странах сейчас идет борьба не ИТ и ИБ, а ИБ и Privacy. Как совместить и то и другое? Как не нарушать конституционные права пользователя на частную жизнь и при этом обеспечивать эффективную работу сотрудника? Неоднократно поднимаемая тема контроля e-mail относится именно к этому направлению. Одно дело запретить заниматься личными делами на работе (нарушает ТК, но многие работодатели так делают) и совсем другое дело, когда такого запрета нет. В этих условиях службам ИБ приходится отходить от концепции "замкнутой среды" и придумывать что-то более гибкое.
• Приход новых вендоров, ранее на корпоративном рынке незамеченных, а следовательно и неучитывающих потребности корпоративных пользователей или учитывающих не в полной мере. Речь идет о Google, Apple, Dropbox и иже с ними. Загрузка корпоративных документов в iCloud, Google.Docs, Dropbox с их малокемчитаемыми политиками с одной стороны повышает надежность хранения, гибкость доступа и удобство обмена с коллегами, а с другой ставит кучу непонятно как разрешаемых задач перед службами ИБ. Причем именно перед безопасниками - айтишникам все эти сервисы никаких особых проблем не доставляют (если не вспоминать про синхронизацию).
• Использование социальных сетей для целей корпоративного маркетинга, привлечения новых клиентов, получения обратной связи от потребителя и т.д. С другой стороны социальные сети начинают использоваться для информационных войн (а кому с ними бороться как не безопасникам), слива (в т.ч. и случайного) конфиденциальной информации, нарушения этических норм и т.п. И обо всем этом тоже стоит задуматься ДО, а не ПОСЛЕ начала их активного использования.

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

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

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

Подробнее…

ФСТЭК сменила сайт. Лучше бы не меняла...

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

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

Ну и наконец сайт ФСТЭК. Он обновился аккурат вчера, хотя многие специалисты наблюдают за ЭТИМ уже давно - ссылка на тестовую версию висела на главной странице сайта ФСТЭК больше полугода. Обсуждать контент сейчас не буду - частично он переехал с предыдущей версии, частично он новый, что-то явно будет еще наполняться (хотя за полгода можно было бы и наполнить). У меня претензии другого плана - к архитектуре, дизайну и тестированию сайта. Проектировал его явно кто-то незнакомый ни с первым понятием, ни со вторым, ни с третьим.

В Facebook коллега хорошо высказался на эту тему: "Реальный треш. Так и вижу, как сотрудник ФСТЭК просит 17 летнего сына и его знакомых создать новый дизайн сайта… Ладно Россия отстает от Запада по многим направлениям включая лживую девку кибернетику, но создавать сайты по образу 2000 года, живя в 2012 это конечно тихий ужас. Гораздо проще не просить сына, а заплатить 20-30 тысяч фрилансеру в Новосибирске и на выходе получить что-то более-менее в стиле современности. Вообщем проклятое место. Собирали Ламборджини, а снова вышел АвтоВАЗ".

У меня аналогичное впечатление - сайт создавали на коленке те, кто взял в руки учебник по Joomla и стали выполнять его рекомендации; пропустив первый раздел о планировании информационной архитектуры. Именно она определяет, какая информация будет содержаться на сайте, как к ней организовать удобный доступ, кто целевая аудитория и т.д. и т.п. Ну разве непонятно было, что стоило всю информацию четко разделить на 2 больших блока - экспортный контроль и техническая защита конфиденциальной информации? Это позволило бы сразу разделить аудитории. В экспортный контроль не лезу, а раздел по ТЗКИ можно было бы разделить как минимум по двум срезам:

• По аудитории. Я их вижу по крупному 4 - лицензиаты-оказатели услуг, сертификаторы, разработчики, потребители. Они почти не пересекаются по используемой информации.
• По задачам. Их тоже немного - лицензирование деятельности, аккредитация лабораторий, сертификация продуктов, рекомендации/требования по защите, контроль и надзор.

И это все лежит на поверхности. Ну почему бы не посетить сайты аналогичных ведомств в других странах и посмотреть, как сделано "у них". Австралийцы, американцы, канадцы... Ну почему их сайты не вызывают отторжения? Ну почему там и без Артемия Лебедева дизайнеры есть и способы сделать что-то простое, но при этом удобное в использовании?.. Ну а про работоспособность сайта в различных браузерах я вообще молчу. У меня в Firefox текстовые блоки наезжают друг на друга, а часть ссылок не срабатывает с первого раза. В Safari та же проблема. У коллег проблемы с просмотром в Хроме. Пожалуй, только в Internet Explorer все работает более-менее. На смартфоне и планшетнике ситуация еще хуже - видимо о специальных мобильных версиях для сайтов разработчики не слышали.

В общем хотелось как лучше, а получилось как всегда. Задумки-то неплохие - тут и английская версия (покоцанная, правда), и RSS, и кнопки "поделиться" в разных социальных сетях, и политика работы с ПДн... Но как-то это все недоделано. Не хватает ФСТЭК специалистов по digital marketing, которые бы выстроили грамотную стратегию продвижения ФСТЭК в Интернет и помогли бы составить правильное техническое задание для разработчиков сайта.

ЗЫ. Старая версия была гораздо удобнее нынешней с точки зрения навигации и дизайна (его там просто не было, а потому он и не мешал).

Подробнее…

С наступающим Новым Годом!

 

Ухожу в Новый год! Там и свидимся!

ЗЫ. Для тех, кого интересует, кто рядом со мной. Это мое альтер эго. А как вы думали, я пишу так часто и так много?! Без помощников никак ;-)

Подробнее…

Прогнозы на грядущий год Змеи

Пришла пора поговорить и о прогнозах на грядущий год змеи. Тема эта благодарно-неблагодарная. Почему неблагодарная? Потому что предсказывается не то, что реально может произойти, а то, с чем неплохо знаком предсказатель. Вот пример сравнения предсказаний 7 различных вендоров по ИБ на 2012-й и 2013-й года. Разброс очень сильный. Поэтому буду говорить о более-менее ясных мне вещах, т.е. о законодательстве. Разумеется, это будут не 100%-е прогнозы, но 80%-ую вероятность определенно могу гарантировать. Итак можно выделить несколько направлений регулирования, которые будут занимать умы и регуляторов и специалистов по ИБ:

1. Персональные данные
• Приказ РКН об утверждения списка стран с адекватной защитой прав субъектов ПДн. Предполагаемая дата принятия - 1-й квартал 2013 года.
• Методические рекомендации по обезличиванию ПДн. Предполагаемая дата принятия - 1-й квартал 2013 года.
• Приказ ФСТЭК по защите ПДн. Предполагаемая дата принятия (включая регистрацию в МинЮсте) - 1-2-й кварталы 2013 года. 
• Приказ ФСБ по защите ПДн. Предполагаемая дата принятия (включая регистрацию в МинЮсте) - 1-2-й кварталы 2013 года.
• Постановление Правительства о надзорных функциях РКН в части защиты прав субъектов ПДн. Предполагаемая дата принятия - 2-й квартал 2013 года. 
• Закон о внесении изменений в КоАП (в части увеличения штрафов). Очень предполагаемая дата принятия - 2-й квартал 2013 года.
• Закон о внесении изменений в различные законодательные акты в связи с принятием  Евроконвенции. Предполагаемая дата принятия - 2-й квартал 2013 года.
• Методика моделирования угроз (она же будет применяться и для госорганов). Дата принятия пока не определена.
• Детальное описание состава мер, определенных в приказе ФСТЭК по защите ПДн. Дата принятия пока не определена.
• Обсуждение поправок ФЗ-152, связанных с переходом в 2014 на новую редакцию Евроконвенции
2. Финансовая отрасль (по данному вопросу очень рекомендую посетить Магнитогорскую конференцию - там будут представлены все регуляторы на самом высоком уровне, включая руководителей ГУБЗИ и ДРР Банка России)
• Новая версия СТО БР ИББС. Дата принятия пока не определена, но предполагаю, что это будет скорее второе полугодие.
• Русский перевод PCI DSS. Дата принятия пока не определена, но предполагаю, что это будет первое полугодие.
• Методика проведения проверок надзорным блоком ЦБ по 382-П. Дата принятия пока не определена, но предполагаю, что это будет скорее второе полугодие, а может и в первом успеют.
• Внесение изменений в 382-П и 2831-У, а также разъяснения по их применению.
• Новые требования по защите информации при переводе электронных денежных средств.
• Новая форма отчетности (406) по инцидентам по платежным картам (невысокая вероятность, но слухи ходят).
3. Госорганы
• Приказ ФСТЭК по защите государственных информационных систем (новый СТР-К). Предполагаемая дата принятия (включая регистрацию в МинЮсте) - 1-2-й кварталы 2013 года.
• Детальное описание состава мер, определенных в приказе ФСТЭК по защите госорганов. Дата принятия пока не определена.

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

И еще немного о нормотворческой деятельности ФСТЭК. Она вновь возвращается к своей методологической роли и планирует выпустить в грядущем году новые требования к новым средствам защиты (DLP и средства доверенной загрузки); обновится РД и по межсетевым экранам (к концу года). В рамках ТК362 ФСТЭК планирует разработать несколько интересных ГОСТов, среди них стандарты по ИБ виртуализации и облачных вычислений.

Кстати, сейчас намечается интересная тенденция. Отрасль сыта по горло темой "как обнаружить" или "как отразить" те или иные угрозы. Она безусловно важна, но что-то новое в ней найти и предложить сложно.  Поэтому акцент сейчас смещается в другие направления:

• Что делать, чтобы угрозы вообще не реализовывались, т.е. тема SDLC, которая в 2013-м году может выйти из загона и начать набирать своих сторонников. Тем более, что и некоторая нормативка под это дело готовится со стороны разных регуляторов.
• Что делать, если инцидент уже произошел, т.е. как раз тема киберпреступности, которая активно проявилась именно в 2012-м году и в следующем году будет только наращивать свою популярность.
• Как правильно управлять ИБ на предприятии? Именно операционное и стратегическое управление, а не "тупое" использование классных ИБ-продуктов. Сейчас этому вопросу уделяют не так много внимания, т.к. темы "неденежные" для многих игроков рынка. Продуктов там почти нет, консалтинг непрост (тут опыт нужен), специалистов, готовых делиться опытом тоже маловато. Но думаю, что эту тему начнут двигать.

Тема "как отразить" тоже будет продолжаться, но в относительно новых областях, которые в 2012-м году только начинали развиваться в России - безопасность мобильных технологий, индустриальных систем, виртуализации, облаков.

Примерно так получается. Разумеется, я рассказал не обо всем, что будет в 2013-м году в России, но ключевые вопросы осветил. Год уходящий был интересным; год грядущий будет не менее интересным. Нам всем будет чем заняться, а может и чем гордиться (каждому свое).

UPDATE: Планы ГУБЗИ на 2013 год в интервью Сычева А.М.

UPDATE 2: Путин порекомендовал ФСБ быть в киберпространстве поактивнее; особенно в части КВО, киберпеступлений и контрразведки.

Пока же хочу пожелать всем читателям в Новом году всех свойств Змеи, о которых говорят в различных мифологических традициях:

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

Подробнее…

Чем мне запомнился 2012 год: часть третья, финальная

В финальной части анализа итогов 2012-го года с точки зрения информационной безопасности я хочу остановиться на двух моментах. Первый - это провал выстаовк по информационной безопасности и изменение формата проведения мероприятий по ИБ. Про провал (несмотря на победные реляции организаторов) Инфобеза и Infosecurity не писал только ленивый - повторяться не буду. Причин тут, на мой взгляд, несколько. И непонимание организаторами отечественного рынка ИБ (а может быть и нежелание инвестировать в такое мероприятие), и отсутствие продуктового рынка как такогого, и незрелость эскпонентов. Михаил Емельяников про это хорошо написал.Зато изменилась конференционная часть. Я про это тоже писал неоднократно. Например, тут или тут. PHD, ZeroNights, ИнфоБЕРЕГ, IT & Security Forum, Уральский Форум - яркие примеры того, как можно делать неплохие мероприятия.

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

1. Первый позитивный опыт общения с регуляторами был еще в 2009-м году, когда ЦБ под эгидой АРБ собрал экспертную группу для работы над 4-й (текущей) версией СТО БР ИББС в части регулирования вопросов защиты прав субъектов ПДн и защиты самих ПДн. Потом был опыт работы с ЦБ в части разработки 382-П. И сейчас ЦБ не прекращает эту деятельность, привлекая внешних экспертов для разработки и экспертизы тех или иных нормативных актов, включая СТО БР ИББС и т.д.
2. Другой позитивный опыт общения с регуляторами зафиксирован с Роскомнадзором. Именно в результате такого общения Роскомнадзор выпустил разъяснение по вопросам, касающимся обработки персональных данных работников, соискателей на замещение вакантных должностей, а также лиц, находящихся в кадровом резерве. И это только первый шаг, за которым, я надеюсь, последуют и другие.
3. Про взаимодействие с ФСТЭК я писал неоднократно и с точки зрения открытости они сейчас, наверное, находятся на первом месте, обойдя даже Банк России по этому показателю. Выложенные на сайте документы, приглашение присылать свои замечания и предложения (особенно предложения, а не огульную критику "все плохо - переделать"), учет полученных предложений, выкладывание результатов рассмотрения каждого полученного предложения... Просто отлично на мой взгляд. Разумеется, сделать процесс более автоматизированным было бы неплохо - какую-нибудь платформу краудсорсинга замутить или формализовать процедуру общения с экспертным сообществом. Но с чего-то надо начинать.

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

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

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

И если работа пойдет и число экспертов, которые начнут писать в ФСТЭК свои предложения, перевалит хотя бы за 2-3 десятка, то я склонен согласиться с Евгением Родыгиным, что надо каким-то образом привлекать профессиональные сообщества для взаимодействия с регуляторами. Экспертные, общественные, консультативные советы при ФСТЭК или ФСБ - это хорошо, но этого недостаточно. Профессиональные объединения (RISSPA, DLP-Эксперт, АБИСС, не к ночи упомянутая АРСИБ, АДЭ, РАЭК, НП НПС) должны стать связующим звеном или площадками, к которым обращаются регуляторы, и на которых затем обкатываются ответы регуляторам, чтобы последние не сталкивались с десятками или сотнями частных предложений. Это позволить формализовать и пустить в нужное русло процедуру экспертного обсуждения всех новых нормативных актов в области информационной безопасности.

Подробнее…

Чем мне запомнился 2012 год: часть вторая

Что еще было знаменательного в году уходящем? Регуляторы и нормативная база. Они уже стали притчей воязыцех и врядли в году Змеи перестанут свою деятельность; они вошли во вкус. 3-го декабря я уже приводил статистику за 2012 год - за этот месяц ситуация почти не поменялась, исключая появление проектов документов РКН по обезличиванию, проекта приказа ФСТЭК по ПДн, и рекомендаций ЦБ по выполнению 9-й статьи ФЗ-161 и рекомендаций НП НПС по применению электронных средств платежа. Так что усредненная цифра в 4 нормативных акта в месяц соблюдена и в декабре.

В 2013-м году регулирование продолжится. Будут выпущены финальные варианты приказов ФСТЭК и ФСБ по персданным, выйдет приказ ФСТЭК по госорганам, Правительство весной планирует внести в Госдуму поправки в отложенный закон об электронной подписи, ЦБ продолжит регулирование защиты информации при осуществлении денежных переводов (как в части обновления 382-П и 2831-У, так и в части выпуска новых требований - "русского" PCI DSS, положения о защите информации при осуществлении переводов электронных денежных средств), выйдет новая версия СТО БР ИББС, ФСТЭК продолжит тему регулирования облаков и начнет заниматься виртуализацией, выйдет методика моделирования угроз и подробное описание состава и содержания защитных мер, перечисленных в проектах приказов по госорганам и персданным. Законопроект о росте штрафов за нарушение ФЗ-152 тоже наконец-то примут, как и проект приказа по методам обезличивания и проект приказаа со списком "адекватных" стран. И т.д. Работа регуляторам предстоит большая, а ведь еще у нас есть законодатели, которые тоже могут преподнести немало сюрпризов.

Еще одним событием уходящего года можно назвать попытку России всеми правдами и неправдами нусилить свое регулирование Интернет. Пока она выразилась только в принятии 139-го федерального закона о защите детей и внесении поправок в 149-й трехглавый закон. Но на мой взгляд это только первая ласточка. На 139-м законе обкатали процедуру и риторику и не исключаю, что в условиях роста политической и социальной нестабильности в России, власти захотят распространить положения 139-ФЗ на вопросы экстремизма с его расширительным толкованием. В осеннюю сессию так и не удалось принять закон о запрете анонимайзеров, но идея не умерла и возможно ее просто решили расширить и углубить, перенеся на весеннюю сессию депутатов.

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

Подробнее…

Чем мне запомнился 2012 год: часть первая

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

Начну, пожалуй, с относительно новой темы - борьбы с киберпреступностью. Мне эта тема напоминает то, что несколько лет назад происходило с DLP. Тогда была всего одна компания - Infowatch, которая и драйвила эту тему на всех уровнях - выступления на конференциях, статьи, презентации, исследования... Потом к Infowatch подтянулись Инфосистемы Джет, а потом уже пришли и другие игроки рынка, уже международного уровня (Symantec, Websense и т.д.). В мире эта тема как-то уже и не вспоминается особо, развиваясь своим чередом; у нас же все растет буйным цветом...

Борьба с киберпреступностью (борьба с мошенничеством) похожа на DLP. Очевидно, что возникла она не на пустом месте - борьбой с киберпреступниками и мошенниками в России занимаются очень давно. Но именно в уходящем году эта тема стала ну очень уж активно продвигаться на различных конференциях, в статьях, на радио и даже на телевидении. Наиболее активно эту тему двигает Group-IB, что и понятно - специализированная компания, оказывающая специализированные сервисы. При этом в отличие от DLP, темы раскрученной на пустом месте (утечки были, есть и будут и вряди их стало катастрофически больше или меньше от активизации темы DLP), тема борьбы с киберпреступниками действительно актуальна для многих (особенно пострадавших от хищений). И именно в последние годы рост ущерба от действий киберпреступности стал угрожающим.

Разумеется, тема продвигает не только Group-IB - немало этому способствует Управление "К" МВД. Его хоть часть и ругают за непрофессионализм и непубличность, но ситуация меняется. И люди там есть (хотя и не во всех регионах) и в СМИ стали активно освещаться эти вопросы. Очевидно, что можно делать лучше и больше, но с чего-то надо начинать. АИС с конференцией AntiFraud Russia тоже помогают продвигать данную тему на российском рынке. И конечно этот рассказ был бы неполным без упоминания Банка России, АРБ и НП НПС, которые разработали практические рекомендации по расследованию инцидентов, связанных с мошенничеством в ДБО. У Group-IB также есть свои рекомендации по данному вопросу, расширяющие и дополняющие то, что сделано в НП НПС и АРБ.

Вот такой первый итог 2012-го года. Итог именно для меня. Завтра продолжим подведение иных итогов 2012-го года, а в пятницу попробую что-нибудь спрогнозировать с учетом тех направлений, которыми я занимаюсь.

Подробнее…

Сравнение четверокнижия, приказа 58 и проекта нового приказа по ПДн

Прочитал на DLP-Expert открытое письмо Геннадия Атаманова директору ФСТЭК с резкой критикой нового проекта приказа ФСТЭК. К сожалению, 40 страниц конкретных замечаний, о которых пишет Геннадий, я не видел, поэтому не буду обсуждать данное письмо. Скажу только, что я не согласен с оценкой, данной Геннадием. Я считаю, что новый проект не просто коренным образом отличается от всего предыдущего сделанног оФСТЭК, но и является серьезным скачком вперед, о чем я также написал на DLP Expert'е.

Но чтобы не давать качественных оценок, а говорить предметно, я попробовал сравнить три документа по ПДн, которые ФСТЭК выпустила за последние 5 лет. Речь идет о первом "четверокнижии" 2008-го года, приказе №58 года 2010-го и проекте нового приказа выпуска 2012-го года. Я не стал пока сравнивать наборы защитных мер в этих документах - результат будет явно не в пользу предыдущих документов. Не только по числу защитных мер, но и по их сути. Обманные системы, DLP, обнаружение скрытых каналов, SIEM-решения, терминальный доступ... Всего этого раньше в документах ФСТЭК просто не было. Спорить можно только о "русском языке" в названии предлагаемых защитных мер - там есть что править. Но на качестве документа это не сказывается, на мой взгляд. Тем более, что речь идет о проекте, а не финальной версии, в которой будут еще правки.

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

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

И в чем же тогда ухудшение ситуации, о котором часто говорят эксперты? В отсутствии литературного русского языка? В возможности самостоятельно выбирать оператору защитные меры? В учете используемой для обработки ПДн технологии?

Да, пока не решен вопрос с методикой моделирования угроз. Но документ пишется и в 2013-м году будет опубликован. Вопрос определения актульности типа угроз я считаю неактуальным ;-) В ПП-1119 написано, что это ответственность оператора. Да, пока не понятно, что скрывается за каждой из мер, указанной в проекте нового приказа. Но документ с описанием состава мер также пишется и будет в 2013-м году опубликован.

Так в чем же хуже стало?

Подробнее…

Dell покупает Credant, а Blue Coat покупает Crossbeam

18 декабря компания Dell анонсировала соглашение о приобретении компании Credant, известной своими решениями по защите данных (преимущественно шифрованию) на ПК, серверах, в системах хранения и облаках. Детали сделки не разглашаются. Могу сказать, что я пользуюсь продукцией Credant уже больше пяти лет и никаких нареканий и претензий к ней ней. Да и покупка Credant хорошо укладывается в стратегию и портфельный ряд Dell.

Днем ранее, 17-го декабря Blue Coat анонсировала приобретение компании Crossbeam. И вот тут ситуация сложнее. Во-первых, Blue Coat - это компания, сидящая в двух нишах - Web-безопасности и оптимизации трафика. Как сюда стыкуется высокоскоростная платформа Crossbeam не совсем понятно. Можно предположить, что Blue Coat нуждается в производительном железе для своего софта. Об этом говорит и топ-менеджмент Blue Coat. Тогда что будет с поддержкой, ранее поддерживаемых на платформе Crossbeam конкурирующих с Blue Coat решений? Вероятность, что они перестанут поддерживаться очень высока, т.к. это не укладывается в стратегию Blue Coat.

Второй возникший у меня вопрос связан со схемой сделки. Я не большой знаток инвестиционного бизнеса, и поэтому выглядит это как-то непонятно. Crossbeam в ноябре этого года был куплен инвестиционным фондом Thoma Bravo. Спустя месяц Crossbeam продают Blue Coat'у, который принадлежит... тому же фонду Thoma Bravo (с февраля 2012 года). Получается, что Thoma Bravo купил Crossbeam, а потом продал самому себе же в лице Blue Coat... Хотя для Thoma Bravo такие сделки не в новинку. Они уже управляли NetIQ, которая была продана AttachMate, которая затем была куплена... опять Thomas Bravo. Т.е. купили повторно то, что уже продали...

Подробнее…

Российские силовики проявляют недюжий интерес к банкам

Не хватало банкам контроля со стороны Росфинмониторинга, ЦБ, ФНС, Роспотребнадзора и Роскомнадзора, как внимание к кредитным организациям стали проявлять еще и российские силовики. Причем в тех вопросах, которые раньше как-то не попадали в прицел сотрудников банков; преимущественно региональных. Вот, например, какое письмо получил недавно один из банков:


"В соответствии с Федеральными законами Российской Федерации от 30.06.2003 года № 86-ФЗ "О Федеральной службе безопасности Российской Федерации" и от 12.08.1995 года № 144-ФЗ "Об оперативно-розыскной деятельности", в целях оценки уязвимости информационно-управляющих систем объектов кредитно-финансовой сферы в направлении возможного использования ОТКС в ущерб безопасности России, просим Вас предоставить в наш адрес следующую информацию:

1. Об имеющемся иностранном оборудовании, используемом для выхода в открытые телекоммуникационные сети (Интернет), указать: адрес установки оборудования, наименование, марку, модель, производителя, сроки использования, сбои в работе (периодичность), полные данные обслуживающего персонала (ФИО, дата и место рождения, место регистрации и (или) проживания, контактные телефоны).
2. Имеющуюся техническую документацию на указанное оборудование (копии).
3. Данные о заключенных (находящиеся в стадии проработки) контрактов с иностранными фирмами и организациями на приобретение, поставку и размещение иностранного оборудования, планируемого к использованию для выхода в ОТКС (Интернет), с указанием: данных организации, с которой заключен (планируется к заключению) контракт; наименования поставщика оборудования (реквизиты, контактное лицо)." 

Письмо странное и вызывает смешанные чувства. Во-первых, не совсем понятно, как ответы на данные вопросы поможет ФСБ оценить ущерб безопасности России? Во-вторых, сформулированные вопросы иллюстрируют полное непонимание того, как работают иностранные ИТ-компании в России. Про юридическую безграмотность при составлении данного письма я вообще молчу. Сотрудники ФСБ видимо не удосуживаются хотя бы перечитать то, что они выпускают в свет ;-( Достаточно вспомнить "сотрудники" вместо "работники" в ПП-1119. Можно, конечно, предположить, что это такая тонкая шпионская игра, но как-то выглядит это малореально.

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

Тут безусловно вызывает интерес вопрос об используемом оборудовании и телекоммуникационных средствах. Обо всех, чтоли? Очевидно, что только о тех, что расположены на территории воинской части. Но даже этого немало. Особенно учитывая иностранное происхождение многих используемых в России банкоматов (Diebold, NCR и т.д.). Второй интересный вопрос - про радиоэлектронные средства. Допустим, в банкомате установлен GPRS-модем для резервного соединения с процессингом в случае падения основного канала. Есть ли в банке функциональная схема данного модема, как того требует командир войсковой части? Не уверен. Дальше интересней - МинОбороны в лице командира в/ч требует от банка проведения спецпроверок банкоматов на наличие закладок.

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

Подробнее…

Составлен список стран, адекватных с точки зрения персданных

Составление списка стран, с адекватной защитой прав субъектов ПДн, - это одна из больных тем законодательства о ПДн. Начиная с 2006-го года, вопрос о том, что же такое "адекватная" страна задается постоянно и до прошлогодней редакции ФЗ-152, никто не мог на него ответить. Я про него как-то писал даже. С июля 2011-го года эта обязанность легла на плечи Роскомнадзора, который и должен был составить соответствующий перечень стран.

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

С этим перечнем можно спорить, что в него не включены США и другие "прогрессивные" страны, но такова уж позиция РКН и я не вижу причин для ее изменения. США и в европейский список стран не входят, как и многие другие, казалось бы "адекватные" страны. Некоторые вопросы вызывают страны типа Бенин, Сенегал, Тунис, Ангола... Хотел бы я посмотреть на исходные данные, которые использовались при принятии решения. Но нам их не показывали, да и спорить на эту тему большого смысла я не вижу. Не думаю, что у нас настолько активный оборот ПДн с этими странами. В любом случае, отсутствие США, Японии, Египта, Мальдивских о-вов, Индии, Тайланда, Китая и других государств, куда активно уходят наши ПДн (как минимум, по части туристического обмена), не означает невозможности такой передачи. Просто она становится чуть более сложной - потребуется письменное согласие. Или наличие договора с субъектом, а также ряда иных исключений, указанных в ФЗ-152. Так что сильно на эту тему переживать, на мой взгляд, не стоит.

ЗЫ. Учитывая принятия "акта Магнитского" и "симметричный ответ" России, могу предположить, что США никогда не появится в списке стран, с адекватной защитой прав субъектов.

ЗЗЫ. Думаю, что приказ будет утвержден и зарегистрирован в Минюсте в первом квартале 2013-го года.

Подробнее…

Как РКН дело доброе делал

Все помнят (наверное), что я неоднократно (как минимум дважды) писал о том, что РКН готовится выложить в публичный доступ свои рекомендации по проверкам операторов персданных, которые он рассылает своим терорганам. Об этом мне говорили в РКН, но, к сожалению, дело так и не двигалось с мертвой точки. Внутренняя позиция РКН так и оставалась внутренней и операторы один на один сталкивались с позицией тероргана при проведении проверки.

В начале сентября я был в РКН, где совместно с Романом Валериевичем Шередиными и возникла идея о создании некоторой рабочей группы, которая должна была разработать некий "постатейный" комментарий к ФЗ-152 для того, чтобы и терорганы и операторы ПДн однозначно понимали отдельные нормы закона о персональных данных. В рабочую группу со стороны экспертного сообщества (помимо меня) вошли Михаил Емельянников, Алексей Волков и Александр Токаренко. Со стороны РКН также вошли свои эксперты. Мы выбрали ряд вопросов для выработки единой позиции и вот в пятницу она была опубликована на сайте Роскомнадзора.

Коллеги уже высказались по данному вопросу (тут и тут), поэтому я повторяться не буду. Первый шаг сделан. Будем продолжать. С нашей стороны запал еще есть; со стороны РКН думаю тоже.

Подробнее…

Как Роскомнадзор спамерам помогал

Есть такое требование ФЗ-152 - оператор должен уведомить РКН о начале обработки ПДн, а РКН должен внести такого оператора в реестр. Форма уведомления описана в приказе Роскомнадзора от 19 августа 2011 г. №706 "Об утверждении Рекомендаций по заполнению образца формы уведомления об обработке (о намерении осуществлять обработку) персональных данных", а сам реестр находится в открытом доступе на портале РКН. Это все присказка, сказка будет впереди ;-)

Среди прочего в данном уведомлении указывается "ФИО физического лица, ответственного за обработку персональных данных", а также номера их контактных телефонов, почтовые адреса и адреса электронной почты. А дальше самое интересное. Эта информация в неизменном виде попадает в публичный реестр РКН и затем светится на сайте без каких-либо ограничений. Я не говорю про то, что персональные данные ответственных лиц становятся общедоступными и не факт, что эти лица давали согласие на передачу своих ПДн Роскомнадзору (а Роскомнадзор получает эти ПДн не напрямую от субъекта). Это все лирика, которая не стоит внимания.

Проблема в другом. Указанные лица в соответствие со статьей 18.1 должны находится в подчинении исполнительного органа оператора ПДн, т.е. напрямую подчинятся гендиректору, президенту, совету директоров и т.п. Иными словами люди это, как правило, высокопоставленный и обеспеченные. А тут их контактные данные выложены в свободный доступ... Вот только один пример.

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

Главное, что теперь, эти ответственные люди, которые могли бы помогать решать вопросы защиты прав субъектов ПДн в своих организациях, в гробу видели и персданные, и РКН, и все повторные попытки придти к ним с какой-либо аналогичной инициативой.

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

Подробнее…

Как строится защита государевых информационных систем в США

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

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

 

Третий этап - это уже знакомый для многих процесс, начинающийся с категоризации информационных систем, которая в свою очередь зависит от обрабатываемых в системе данных, их природы, степени конфиденциальности или иной защищаемой характеристики (целостность, доступность, важность и т.д.), архитектуры и других исходных данных, полученных на первых двух этапах. Например, мы можем принять решение, что риски нарушения конфиденциальности нам не важны; а вот риски нарушения доступности или целостности информации гораздо приоритетнее (так, например, будет для gosuslugi.ru). Это достаточно непростой процесс, от эффективности реализации которого зависит то, насколько эффективной будет построенная система защиты. Для помощи в реализации данного этапа американский NIST разработал два стандарта:

• FIPS 199. Standards for Security Categorization of Federal Information and Information Systems
• NIST SP800-60. Guide for Mapping Types of Information and Information Systems to Security Categories.

Определившись с классами информационных систем, мы должны выбрать защитные меры. Они разбиты на три больших блока - технические, операционные, управленченские, которые затем разбиваются на семейства - контроль доступа, повышение осведомленности и тренинги, аудит, планирование, оценка рисков, защита персонала и т.д. Перечислены эти меры в стандарте NIST SP800-53 Recommended Security Controls for Federal Information Systems and Organizations. Сейчас готовится 4-я редакция этого стандарта, которая будет включать и ранее описанные меры по защите персональных данных. Называться этот стандарт будет Security and Privacy Controls for Federal Information Systems and Organizations (номер тот же).

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

При этом существует минимально необходимый набор защитных мер, описанные в FIPS 200 Minimum Security Requirements for Federal Information and Information Systems. Выбор способа реализации этих мер (из NIST SP800-53), как и дополнительные защитные меры, лежат на операторе/владельце информационной системы. При этом документы NIST учитывают две непростых особенности современной информатизации госорганов. Во-первых, их территориальную распределенность и необходимость защиты двух и более связываемых между собой локальных сетей через недоверенные каналы связи. А во-вторых, массовый переход на облачные вычисления также требует от госорганов, чтобы функции выбора защитных мер могли быть делегированы от владельца защищаемых данных к владельцу информационной системы (облачному провайдеру), в которой эти данные обрабатываются.

Выбрав защитные меры, мы приступаем к их внедрению. Для этого у NIST разработана масса документов по особенностям защиты различных информационных технологий - облаков, мобильных устройств, АСУ ТП, Wi-Fi и WiMAX и т.д. При этом NIST разработал и рекомендации по различным организационным и управленческим процессам - оценка рисков, повышение осведомленности персонала, расследование инцидентов и т.д. Т.е. NIST планомерно закрывает те пару десяткой семейств защитных мер, описанных в SP800-53.

По окончанию внедрения мы должны провести оценку эффективности защитных механизмов. Кто-то это называет аудитом, кто-то аттестацией. Важна суть данного процесса, заключающегося в проверке, желательно независимой, сделанных на предыдущих этапах действий по выбору и внедрению защитных мер технического и организационного плана. Проведение такой оценки описано в SP800-53A Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans.

И наконец завершается все этапом непрерывного мониторинга уровня защищенности информационной системы, описанного в недавно выпущенном SP800-137 Information Security Continuous Monitoring for Federal Information Systems and Organizations. И дальше по кругу.

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

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

Третье отличие - в огромном количестве методических документов по защите той или иной информационной технологии или реализации того или иного защитного процесса. NIST уже выпустил свыше ста специальных публикации на этот счет. ФСТЭК - ни одной! Учитывая нехватку специалистов по ИБ, особенно в регионах, методической помощи регулятора очень сильно не хватает.

Четвертое отличие - в том, что происходит после внедения системы защиты и ее аттестации. У нас хоть потоп (до следующей аттестации). ФСТЭК и ФСБ этот вопрос почти не интересует - главное, чтобы бумажки были и оргмеры были соблюдены. А как на деле происходит поддержание необходимого уровня защищенности? Никто не знает. Поэтому и привыкли у нас жить от аттестации до аттестации, от проверки до проверки. В США ситуация иная - есть рекомендации по выстраиванию процесса мониторинга уровня защищенности, реагирования на инциденты, повышения осведомленности персонала, патч-менеджмента и т.п. Иными словами, госорганы США сопровождаются на всем жизненном цикле существования своих информационных систем. И даже на последнем их этапе, выводе из эксплуатации, NIST предлагает свои рекомендации, например, SP800-88 Guidelines for Media Sanitization (руководство по уничтожение носителей защищаемой информации).

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

Подробнее…

Cisco SecCon: постскриптум или почему так важен SDLC

Сегодня закончился второй день конференции SecCon, о которой я начал писать вчера. Основным лейтмотивом мероприятия была защита кода во всех ее проявлениях и на всех стадиях его жизненного цикла - начиная от разработки и тестирования и заканчивая обучением специалистов. При этом, как я уже писал, хотя мероприятия было рассчитано на сотрудников Cisco (собралось человек 300-350), выступали с докладами представители разных компаний. Если не брать в расчет EMC и Microsoft, то в основном доклады были от небольших компаний, которые занимаются различными аспектами SDLC:

• Shenick - небольшая компания, которая предлагает виртуализированное решение для эмуляции трафика и тестирование производительности приложений. Работает на базе всех виртуализированных сред (Hyper-V, VMware, Citrix, KVM) и позволяет проводить нагрузочное тестирование совокупной производительностью до 1 Тбит/сек.
• BreakingPoint (уже часть IXIA) - компания, предлагающая традиционное тестирование, преимущественно сетевого оборудования и средств защиты (МСЭ, IPS и т.д.). К слову сказать, именно BreakingPoint тестирует производительность решений Cisco.
• KoreLogic - более известная по своему участию в DefCon консалтинговая компания, которая предлагает широкий спектр достаточно традиционных услуг - аудит, пентесты, анализ продуктов, управление инцидентами, мониторинг угроз, обучение и, конечно же, анализ кода на предмет соответствия SDLC.
• Aspect Security - компания, основной компетенцией которой является обучение в области SDLC и code review (основатель Aspect Security является одним из основателей OWASP). Они предлагают различные программы онлайн-обучения и похоже неплохо существуют в этой нише. Недавно они выпустили облачное решение по анализу Java-приложени, схожее по сути с тем, что предлагает Appercut.
• Codenomicon Defensics -еще одна небольшая компания, активно развивающаяся в области SDLC. Помимо традиционных услуг по анализу кода, повышению осведомленности и т.п., они разработали мощную платформу Defensics для тестирования защищенности кода различных приложений.

Конференция Cisco SecCon, проводимая уже в пятый раз, не только в очередной раз продемонстрировала внимание, которое западные ИТ-компании уделяют вопросам защищенного программирования и анализа кода с точки зрения информационной безопасности, но и показала, что эта ниша достаточно востребована (и востребованность будет расти) и появляющиеся в ней стартапы не пропадут. Выше перечислено всего 5 компаний, сидящих в достаточно узкой нише рынка ИБ, но при этом каждой находится и свой заказчик и свой рынок. Вопреки расхожему мнению, что разработчикам невыгодно вкладываться в SDLC и на этой теме денег не сделаешь, конференция Cisco SecCon показала, что это не так. И в России пока этот флаг пока никто не поднял и не несет с высоко поднятой головой (некоторые зачатки есть в блоге Евгения Родыгина). Даже те компании, которые работают предлагают услуги в этой нише, занимаются только продажей себя и своих решений, но не повышением осведомленности отрасли.

Эта тема достаточно нова для России, но в условиях рост угроз ИБ и появления ПП-1119, распространяющегося на почти 4.8 миллионов юрлиц и индивидуальных предпринимателей (а именно столько их было по данным Росстата в России в 2011-м году), тема защищенного программирования и анализа кода должна привлечь более активное внимание со стороны отечественных регуляторов. Но пока, насколько я знаю, кроме первых заявлений Банка России о том, что разработчики банковских и платежных приложений в рамках НПС должны соблюдать минимальные требования по ИБ, дело не идет; ни ФСТЭК, ни ФСБ об этом активно не говорят.

Подробнее…

Citrix покупает Zenprise

5-го декабяря Citrix подписал соглашение о покупке Zenprise, компании являющейся одним из лидеров MDM-сегмента. Детали сделки не разглашаются. Цель сделки понятна - рынок средств управления мобильными устройствами растет, интерес к MDM со стороны заказчиков также возрастает - Citrix решила застолбить место в первом ряду.

Подробнее…

НДВ, SDLC, fuzzing и всякое такое

Нахожусь я сейчас на ежегодной конференции Cisco SecCon 2012, которая как и всегда посвящена совершенно различным аспектам обеспечения информационной безопасности. О прошлогодней конференции я уже писал; теперь обращусь к тому, что говорилось на этой (в первый день).Тон задала Reeny Sondhi (фиг знает, как индийские имена переводятся на русский), директор по качеству безопасности продуктов EMC.

Она рассказывала о проблемах с качеством безопасности (не знаю как нормально на русский перевести security assurance) в современных ИТ-продуктах. Привела достаточно интересную модель зрелости процесса оценки качества ИБ, и место ИТ-лидеров современности на ней. Большинство игроков (Cisco, EMC, Microsoft и другие) уже давно находятся на 3-м уровне, постепенно сдвигаясь к 4-му уровню (всего уровней пять). Если вкратце, то уровни следующие:

1. Выставление требований по безопасности к разрабатываемому продукту при почти полном отсутствии контроля реализации (включая и качество) этих требований.
2. Базовая оценка качества в виде различных процедур Quality Assurance; в первую очередь базовый анализ исполняемого кода пост-фактум.
3. Внедрение SDLC и практик code review в разработку ПО. Собственно этому уровню и был посвящен первый день конференции. Докладчики из различных подразделений Cisco, EMC, Microsoft и других компаний делились своим опытом внедрения SDLC, анализа кода, устранения проблем и т.д.
4. Учет рисков supply chain management. В первую очередь это касается производителей "железа", которые осуществляют сборку или получают запчасти для своих заводов преимущественно из Китая. Последние публичные и не очень скандалы с китайскими закладками в сетевом оборудовании, в процессорах и т.д. очень серьезно обостряют проблему. И если сама проблема не нова, то только сейчас она вышла на такой уровень, что необходимо ее как-то регулировать.
5. Высший уровень (по версии EMC) правильно выстроенного процесса повышения качества ПО с точки зрения безопасности - передача его внешним организациям для тестирования. Но именно как независимая оценка того, что уже правильно было разработано (SDLC) и проверялось самим разработчиком (code review). Просто передача кода для анализа в специалилизрованные компании (завтра будет выступать, например,  Coverity) - это не совсем то, что директор направления EMC относит к 5-му уровню модели зрелости. В России такие решения тоже появляются, что не может не радовать.

И вот тут опять стоит сравнить то, что делается на Западе с тем, что делается в России. Особенно в контексте ПП-1119 и появления в нем темы с угрозами НДВ. Собственно недекларированные возможности могут быть, на мой взгляд, случайными (уязвимости) или целенаправленными (закладками). Возникает вопрос - как с ними бороться? Планируемые документы регуляторов на этот вопрос, к сожалению, не отвечают. Хотя варианты предлагались им различные.

Но это потребует от регуляторов смены всей парадигмы регулирования ИБ и переход от реактивного подхода, заключающегося в требовании реагирования на инциденты, в сторону проактивного, когда мы устраняем саму причину возникновения и развития инцидента. И речь не о идее навесной системы защиты, которую так активно двигают ФСТЭК и ФСБ, а о рекомендациях внедрения SDLC всеми разработчиками российских средств защиты и, возможно, разработчиками иного ПО. Безопасность должна быть интегрированной, а не наложенной. Но это потребует от регуляторов смены парадигмы - необходимо менять акцент и более глубоко копать тему SDLC, code review, agile-разработка и т.д. Совершенно иные компетенции, иные знания, иная квалификация. Но без этого никуда. Чем дальше, тем сложнее будет бороться с новыми угрозами, 0Day-уязвимостями, APT и т.д. Особенно в условиях неразвитости отечественного рынка средств защиты.

Но и не одни только регуляторы должны что-то делать. Движение должно идти с двух сторон. Cами разработчики (и СЗИ и другого ПО), которые должны для себя понять, что внедрение SDLC выгоднее, чем устранение последствий от выявленных уязвимостей или закладок. Правда, пока, и это надо признать, это не более чем разговоры. В России пока невыгодно заниматься этими вопросами. Ведь никто никакой ответственности не несет. Разработчик продает свой софт "as is". Испытательная лаборатория не гарантирует качества своей работы. Орган по сертификации тоже не несет ответственности за выданные им сертификаты соответствия.

Достаточно вспомнить недавний случай с одним из отечественных VPN-продуктов. Через 2 дня после появления пресс-релиза о получении VPN-продуктом очередного сертификата ФСБ на одном из хакерских форумов появляется сообщение о взломе данного продукта. И ничего... Все спущено было на тормозах. Вполне допускаю, что разработчик устранил источник проблемы. Но никакой ответственности он не понес. Сертификат никто не отозвал. Регулятор может и вообще не в курсе, что в Интернете ходят рекомендации по способам обхода сертифицированной СКЗИ.

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

Подробнее…

Какие системы сертификации существуют в США?

Аккурат сегодня закончил я прохождение обучения на тему оценки соответствия средств защиты по различным международным системам сертификации. Как это ни странно, но лидером по числу систем сертификации являются США - у них существует 4 системы сертификации:

• FIPS 140 - проверка корректности реализации криптонрафических характеристик. Признается она, помимо США, еще в Великобритании и Канаде. По своей сути схожа с тем, что организует у нас ФСБ, но система более прозначная и открытая. Секретных требований нет. Уровни сертификации дифференцированы - может проверяться только ПО или с погружением в "железо". Текущая версия FIPS 140-2, но в начале 2013-го (а может и до конца этого успеют) грядет новая версия - FIPS 140-3. Т.е. в США на месте требования не стоят и постоянно дорабатываются с учетом новых реалий в области криптографии и криптоанализа. Причем речь именно о требованиях по сертификации, а не о новых криптоалгоритмах. Время сертификации - от 9 до 13 месяцев; примерно как и в России.
• DoD UC APL - это проверка для МинОбороны США того, как продукт (сетевое оборудование, средство защиты, сервера и т.п.) обрабатывают унифицированные коммуникации. Т.к. в условиях военных действий очень важным является именно взаимодействие между войсками, а современные вооруженные силы давно перешли на различные IP-коммуникации (ВКС, IP-телефония, Telepresence, чаты и т.п.), то при данной сертификации смотрится даже не функциональность с точки зрения защиты, сколько качество реализации поддержки унифицированных коммуникаций и взаимодействие между различными компонентами.
• Army I3MP RPL - сертификация по сути аналогичная предыдущей. В ее рамках проверяется не защитная функциональность, а производительность сетевых решений в различных условиях применения сетевого оборудования армией США.
• IPv6 - это сертификация соответствия требованиям по переходу на протокол IPv6, курс на который принят в госорганах США. Проводится сертификация только для госорганов (исключая военные ведомства).
• NATO IAPC - это оценка соответствия продуктов защиты требованиям Североатлантического альянса (НАТО). Проверяются средства защиты и продукты с соответствующей функциониональностью (тоже сетевое оборудование и т.п.).

В чем особенность американских систем сертификации от российских? Если вкратце, то при общей идеологии оценки функциональности и качества реализации защитных функций, мы различаемся в подходах:

• В США все требования (исключая некоторые требования МинОбороны) являются публичными и любой желающий может с ними ознакомиться на сайтах в Интернет. У нас же публичны только требования ФСТЭК (хотя сама процедура сертификации не очень прозрачна). Требования ФСБ секретные. Требования МинОбороны тоже мало кому известны. Исключая вероятного противника - уж он-то с этими требованиями наверняка знаком ;-)
• Обязательность сертификации только для госорганов и военных ведомств. Никакой обязательной оценки соответствия для операторов персданных и в помине нет. Каждый предприниматель действует на свой страх и риск (в этом Россия и США схожи), но вот в Америке эта самостоятельность проявляется и в выборе средств защиты. У нас же никакой самостоятельности нет ;-(
• Схемы сертификации тоже различаются. Да, и там и тут сертифицируется конкретная версия ПО/железа и при ее смене происходит процесс пересертификации. И там и тут срок сертификации эталонного образца составляет несколько месяцев. Но... там нет такой идиотской схемы, когда сертифицируется конкретный экземпляр. Там именно на производителя возлагается ответственность за контроль качества выпускаемой продукции и ее соответствие эталонному образцу. И в случае несоответствия производитель ответит перед регулятором. А т.к. в США доля рынка средств защиты для госорганов очень весома и терять ее никто не хочет (у нас, кстати, тоже), то вендоры не будут невыгодно заниматься махинациями с ПО и внесением каких-то там непрошедших проверку изменений. Тем более, что пересертификация обновлений - не такая уж и сложная задача. У нас же все сделано через одно место - через гостайну - требования растут оттуда. Никакого доверия производителю - все проверяется и перепроверяется. Для гостайны это понятно, но для коммерческого потребителя-то зачем? Не говоря уже о том, что ему все равно не нужны сертифицированные СЗИ. Особенно в условиях, когда ни производитель, ни испытательная лаборатория, ни орган по сертификации не несут никакой ответственности за плоды своего труда.

Вкратце, наверное все. Обучение было интересным и познавательным. Это самое главное.

Подробнее…

Кто кого и кто под кем?

На прошлой неделе довелось мне слушать Джона Пескаторе, вице-президента Gartner, руководителя всех исследований Gartner по информационной безопасности. Сам доклад был достаточно интересным, но хотелось бы мне коснуться только одного из его моментов. Его спросили о том, каковой должна быть подчиненность руководителя ИБ? Должен ли он быть под CIO или лучше использовать другие варианты?

Ответ на вопрос, который часто задается и на отечественных мероприятиях (а лет 5-6 назад я даже вел круглый стол на эту тему), был универсальным и многозначительным, как и почти все рекомендации, которые дают крупные консалтинговые агентства без привязки к конкретики. Пескаторе сказал, что им приходится сталкиваться с разными вариантами подчинения - под CIO, под CEO, под CFO, под CLO (главный юрист), под COO (операционный директор), под CRO (главный за риски) и т.д. Самого правильного места в иерархии нет. Все очень сильно зависит от множества условий - от истории компании, ее структуры, области действия CISO и т.п. Если директор по ИБ отвечает преимущественно за защиту информации в информационных системах, то ему самое место быть под CIO, а если он смотрит шире и защищает информацию в ее разных представлениях, то под CIO ему будет тесновато, т.к. как раз CIO оперирует только информационными системами, "закрывая глаза" на информацию на бумаге. Ну и т.д. Но интересно было другое.

Пескаторе плавно перешел на другую похожу проблему. Под кем должен быть CPO (Chief Privacy Officer)? В России такой должности я не встречал ни разу и наиболее близким по сути является ответственный за обработку персональных данных в организации. Privacy - это конечно гораздо более объемное понятие, чем персональные данные, но все-таки они очень схожи. Поэтому вопрос можно было бы сформулировать и по-русски - под кем должен быть главный за персданные в организации? Под руководителем ИБ или еще под кем? Пескаторе рассказал, что они, как правило, сталкиваются с тем, что CPO рапортует CISO, но это на его взляд не совсем правильно и напоминает конфликт CISO и CIO. Не может контролер находиться в подчинении у контролируемого (не случайно в 242-П Банк России считал, что информационная безопасность - это часть системы внутреннего контроля и должна подчиняться напрямую совету директоров). Также и с CPO. Его задача (если не рассматривать чисто российскую практику выполнения законодательства для галочки и защиты от регуляторов, а не реальной защиты субъектов ПДн) сделать так, чтобы в компании персданных и иной личной информации обрабатывалось как можно меньше. А задача CISO обратная - ему нужно как можно больше данных для изучения поведения пользователей, прогнозирования инцидентов, сбора доказательств и т.п. Задачи CISO и CPO зачастую диаметрально противоположны. Примерно как задачи общества и силовых структур - одни против вмешательства в частную жизнь, другие - всеми частями тела за.

Рецепта Джон Пескаторе не дал. Да он и не мог его дать. Каждая компания по своему решает этот вопрос. Главное, четко понять, какие цели преследуются каждым из руководителей (CIO/CISO, CISO/CPO), какие задачи перед ними стоят, какие полномочия им нужны, как разруливать конфликты и эскалировать их наверх? И тогда уже решать, кто кого и кто под кем?..

Подробнее…

Статистика по российскому законодательству за второе полугодие 2012 года

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

Тенденция выноса темы ИБ на уровень Федерального закона или Постановления Правительства сохраняется.

Сфера применения нормативных актов делится достаточно условно, но в целом, основные требования касаются потребителей (банки, участники НПС, операторы связи и т.д.). На втором месте средств защиты и затем ИТ-продукция. Категория "рынок" объединяет в себе все предыдущие категории вместе взятых и касается сразу всех.

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

Инициаторами нормативных актов являются различные органы исполнительной (преимущественно) и законодательной власти.

Большинство актов уже принято, но чуть меньше половины еще ждет своего часа (тут и отечественный перевод PCI DSS "имени Банка России", и документы по персданным, и "новый СТР-К" и т.д.).

Четверка наиболее попавших под раздачу также не поменялась - участники НПС, госорганы, операторы связи и банки. Категория "все" означает, что в нормативном акте не сделало различий и он распространяется сразу на все организации (например, требования ФСБ по ЭП или ФЗ-152 и т.п.).

Ну и напоследок динамика принятия нормативных актов. За последние полгода отмечается некоторое "затишье" ;-)

Подробнее…