понедельник, 10 ноября 2014 г.

Мои 5 копеек про конференции ИБ

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

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

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

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

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

  Общее количество докладов      64
  Представители заказчиков 34
  Представители интеграторов 25
  Прочие 5
  % представителей интеграторов 39 %

А теперь давайте для сравнения посмотрим на три ИБ-конференции: IT & Security Forum (Казань), BIS Summit, Код информационной безопасности (Казань).

IT & Security Forum

  Общее количество докладов      47
  Представители заказчиков 1
  Представители интеграторов 46
  Прочие 0
  % представителей интеграторов 98 %

BIS Summit

  Общее количество докладов      24
  Представители заказчиков 3
  Представители интеграторов 20
  Прочие 1
  % представителей интеграторов 83 %

Код информационной безопасности (Казань)

  Общее количество докладов      22
  Представители заказчиков 0
  Представители интеграторов 22
  Прочие 0
  % представителей интеграторов 100 %


Ну в общем цифры говорят сами за себя.  Какие выводы я хотел бы из этого сделать. 

1) Я не выступаю против вендорских/интеграторских докладов. Я сам теперь представляю разработчика, но я считаю что на сцене должны быть те, кому действительно есть что сказать и кого интересно послушать по конкретной теме (не важно кого он представляет). И если среди выступающих будет больше людей, которые будут рассказывать про собственные успехи и неудачи, от этого глобально выиграет все сообщество.  Пора перестать уже все скрывать, действуя по старому и неработающему принципу security through obscurity.

2) Многие западные конференции (и аналогичную практику я вижу в конференциях по разработке ПО) задолго до начала организуют сбор заявок на выступления (Call for Papers), это значит что потенциальные спикеры заранее презентуют концепт и суть своего выступления, а организаторы выбирают то, что как им кажется будет интересно их аудитории. Думаю что такой подход стоит перенять.

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

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

среда, 5 ноября 2014 г.

У безопасника должна быть карта сети !


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

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

Мы в команде R-Vision считаем, что эту проблему можно и нужно решать и именно поэтому мы в течение всего 2014 года вели разработку нового модуля по инвентаризации и визуализации данных об инфраструктуре.

Результаты нашей работы мы представим на вебинаре 11 ноября в 10:00.  Приходите !

Подробности и регистрация тут - https://rvision.pro/event/vebinar-asset-manager/

Количество участников (к сожалению) ограничено.

среда, 8 октября 2014 г.

Моя статья для БДИ на тему управления рисками ИБ

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

Журнал можно свободно скачать по ссылке - http://bis-expert.ru/bdi

Далее размещаю текст статьи. 

Риск-менеджмент – живой и мертвый

Александр Бондаренко, генеральный директор R-Vision

В теории нет разницы между теорией и практикой,
а на практике она есть.
 
Йоги Берра, американский бейсболист


Об оценке и управлении рисками говорится много, но реально работающий, «живой» процесс управления рисками ИБ встречается довольно редко. Чаще такая деятельность либо вообще не ведется, либо оказывается «мертвой»: она, вроде как, есть, но ее результаты, да и само ее существование мало кого интересуют. Мы рассмотрим ключевые особенности, отличающие «живой» процесс управления рисками ИБ от «мертвого», и познакомимся с опытом руководителей, которым удалось добиться неплохих результатов при реализации таких процессов.

Поддержка руководства

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

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

Изначально в Ханты-Мансийском Банке внедрение процесса риск-менеджмента ИБ было инициативой службы информационной безопасности. Помимо всего прочего это обуславливалось необходимостью выполнения требований законодательства, стандартов PCI DSS и СТО БР.


Дмитрий Морев, начальник Управления информационной безопасности Ханты-Мансийского Банка

Интеграция с бизнесом

Правильно работающий бизнес – это живой организм, функционирующий как единая система. Любой процесс, который не сообщается с другими, заранее обречен на отмирание либо на существование с помощью искусственного стимулирования. Все это относится и к управлению рисками ИБ. Интеграция может быть обеспечена несколькими путями:
  • результаты оценки рисков используются для получения определенных бизнес-результатов (снижение размеров страховых премий, повышение финансовых рейтингов, соблюдение требований, необходимых для реализации соответствующего бизнес-проекта, и др.); 
  • результаты оценки рисков ИБ включаются в общую карту рисков и рассматриваются топ-менеджментом наравне с другими общекорпоративным рисками. 
Развитию риск-менеджмента в нашей компании способствовал, в том числе, ежегодный внешний аудит международного рейтингового агентства Fitch Ratings. В ходе аудита за 2013 г. были запрошены завизированные руководством документы, подтверждающие использование риск-менеджмента. Мы эти документы сразу предоставили, причем даже с доказательствами их практической реализации. И когда нам повысили международный рейтинг с «B+» до «ВВ-», а национальный – с уровня «A(rus)» до «A+(rus)», статус документов ИБ, передаваемых аудиторам, вырос. Соответственно, вырос и статус рискового подхода к управлению информационной безопасностью.


Андрей Ерин, директор Департамента информационной безопасности «Carcade Лизинг»

Подходящая методика

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

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

Несмотря на обилие методик оценки рисков (одно из немногих исследований на данную тему, проведенное в 2006 г. европейским агентством ENISA, выявило их более десятка – https://www.enisa.europa.eu/activities/risk-management/files/deliverables/inventory-of-risk-assessment-and-risk-management-methods), все они предлагают проводить оценку по очень схожим алгоритмам. Различия между методиками состоят лишь в некоторых методических деталях.
В нашей компании риски ИБ рассматриваются в совокупности с другими общекорпоративными рисками и включаются в общую карту рисков. Ее отправляют на рассмотрение в комитет, состоящий из топ-менеджеров компании во главе с генеральным директором. Ключевые риски также рассматриваются советом директоров.

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


Денис Персанов, Compliance and Risk Management, QIWI

Ограниченное применение

Риск-менеджмент – это инструмент ограниченного применения, и использование его для всех активов/процессов компании напоминает пальбу из пушки по воробьям. В большинстве случаев основные риски видны и без применения какой-либо специальной методики (что, кстати, порождает скепсис в отношении необходимости риск-менеджмента как такового), а для их минимизации достаточно реализовать ряд базовых защитных механизмов (как правило, 5–6 мер обеспечивают минимизацию до 80% угроз).

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

Другой вариант – реализация многоуровневого подхода. В таком случае подбираются разные степени детализации (а возможно, и методики) оценки рисков для разных активов/процессов компании. Это дает возможность, с одной стороны, реализовать риск-менеджмент в том или ином объеме в отношении всех возможных объектов, а с другой, не перегрузить ответственных лиц непомерным объемом работы.
Процесс управления рисками ИБ у нас уже внедрен, но полностью задокументирован и утвержден только для некоторых бизнес-процессов. В рамках этих процессов мы стараемся максимально приблизиться к требованиям стандарта ISO 27001. В остальной же части компании оценка рисков ИБ применяется для общего планирования деятельности и годового бюджетирования департамента ИБ. Различия заключаются в применяемых методиках оценки рисков и в степени детализации.

В первом случае мы абсолютно уверены в том, что все активы в процессах учтены, что мы знаем все уязвимости, угрозы и вероятность их реализации. В рамках оценки мы переводим качественные показатели (экспертное мнение и статистика инцидентов) в количественные и выводим конечное значение критичности соответствующего риска с применением математического аппарата. Таким образом, мы уменьшаем влияние субъективного мнения экспертов.

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


Андрей Ерин, директор Департамента информационной безопасности «Carcade Лизинг»

Сокращение ресурсных издержек

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

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

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


Денис Персанов, Compliance and Risk Management, QIWI

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

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

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


Дмитрий Мананников, директор по информационной безопасности «СПСР-Экспресс»

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

пятница, 26 сентября 2014 г.

Дайджест от R-Vision. Будьте в курсе происходящего !

Коллеги, некоторое время назад мы открыли свободную подписку на дайджесты, которые рассылаем по нашим клиентам.  В условиях тотальной нехватки времени и возможности уследить за происходящим такого рода формат кажется нам наиболее оптимальным. Сейчас дайджест выходит раз в 2 недели и содержит в себе подборку актуальной информации по изменениям в законодательстве, интересным событиям в области ИБ, публикациям и громким инцидентам. Все это и многое другое вы можете получать на свой электронный ящик совершенно бесплтано. Достаточно подписаться тут:  http://eepurl.com/BpV9X

P.S. Сейчас дайджест также транслируется на площадку ISM:Маркет - https://ismmarket.ru/digest, но в ближайшее время эта трансляция прекратится.

вторник, 23 сентября 2014 г.

Типичные уловки злоумышленников в Facebook. Покажите это своим коллегам !

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

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

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

"Дружище, я надеюсь, что ты получишь это сообщение вовремя. Я сейчас нахожусь в поездке в г. Манила(Филиппины) и у меня украли сумку со всеми документами и личными вещами. Посольство только что выписало мне временный паспорт, но я должен заплатить за билет и урегулировать вопрос с оплатой счета за гостиницу.”

“Мне удалось связаться с моим банком, но на получение денежных средств уйдет 3-5 рабочих дней, это плохая новость т.к. у меня в ближайшее время должен быть обратный рейс, но у меня возникли проблемы с оплатой гостиничного номера и меня не выпускают из отеля пока я не заплачу. Мне нужна твоя помощь с оплатой, обещаю все вернуть как только доберусь домой. Ты - моя последняя надежда, пожалуйста, дай мне знать, если я могу рассчитывать на твою помощь. Я буду продолжать проверять свою электронную почту пока не получу какой-нибудь ответ, потому что сейчас для меня это единственный способ связи”.

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

Прием № 2. Посмотрите на тех, кто просматривал ваш профиль !

Facebook, в отличие от некоторых других социальных сетей, не дает возможность посмотреть тех, кто заходил на вашу страницу. Этой опции просто НЕТ ! 

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

Вычислить это довольно легко, ссылки в подобных сообщения всегда ведут за пределы Facebook (посмотрите что в адресной строке браузера).  Все настройки Facebook возможны только внутри Facebook.  Любая внешняя ссылка - это первый признак мошенничества.

Прием № 3.  Если я наберу 100 тыс. лайков, я поеду в Диснейленд

Наверняка вам приходилось такое видеть. Сюжет может быть самый разнообразный, от душещипательной картинки больного ребенка, который сможет получить дорогостоящее лечение, если его сообщение соберет > 100 тыс. лайков, до каких-то увеселительных приколов или игр.   Казалось бы, что может быть опасного в лайках ?  Почти ничего, если не считать, что Like - это валюта Facebook. А значит, что за них конкретные люди получают вполне себе реальные деньги. Страница, получившая 100 тыс. лайков, может быть продана примерно за 200$. Больше лайков - больше денег. После продажи содержимое страницы меняется на то, которое нужно владельцу. И вот тут-то самое интересное - ваш лайк при этом остается на этой странице навсегда (точнее до тех пор, пока вы его не уберете).  И вполне может быть, что кто-то из ваших друзей может удивиться, увидев ваш лайк под страницей, рекламирующей средства от импотенции (например). Хотя "голосовали" вы за милого ребенка, которому родители якобы пообещали билет в Диснейленд за 100 тыс. лайков. 

Прием № 4. Сообщение от Facebook

“Внимание: Ваш аккаунт признан нарушающим политику Facebook и будет отключен в течение 24 часов если не будет проведена процедура подтверждения". Типичный трюк, жертвами которого очень часто становятся и пользователи других онлайн сервисов (надо сказать, что такой прием - один из ведущих способов кражи паролей доступа к электронной почте). Ссылки в такого рода сообщения также как правило ведут за пределы Facebook, где вас попросят подтвердить свои учетные данные. Здесь важно помнить, что Facebook, равно как и другие онлайн-сервисы, никогда не просят вас сообщать свой логин/пароль для подтверждения или снятия блокировки. И конечно же обращайте внимание на адресную строку браузера. Если сайт выглядит как социальная сеть, но в адресной строке указан совершенно незнакомый адрес - закрывайте страницу, это мошенники.

Прием № 5. Смерть знаменитости 

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

И то, что вы получили эту ссылку от ваших друзей к сожалению никак не говорит о ее достоверности.  Такого рода "новости" разлетаются по Facebook с огромной скоростью. 

Прием № 6.  Слишком хорошее предложение

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

Будьте осторожны ! Желаю вам не стать жертвой мошенников из социальных сетей !

вторник, 16 сентября 2014 г.

Agile в жизни безопасника

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

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

И надо сказать книжек про это написано огромное количество. Вот, например, на Amazon:


Они конечно все англицком, на русском мало что можно найти, но все же можно:

http://agilerussia.ru/methodologies/borisvolfson_ebook/ - обзор инструментов Agile (для общего понимания)

http://agilerussia.ru/books/scrum_xp-from-the-trenches/ - практика применения Scrum

http://scrum.org.ua/wp-content/uploads/ScrumAndKanbanRuFinal.pdf - практика применения Scrum и Kanban.

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

Я, например, использую Scrum в управлении своими задачами, где в качестве спринта выступает календарный месяц. Удобно, наглядно.

В этой заметке я затрону только 2 инструмента agile: Scrum и Kanban. 

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

Основные инструменты в рамках этого фреймворка:

1) Разбиение всей работы на небольшие фрагменты (длительность 2-4 недели), которые называются спринтами. Спринт жестко фиксирован по времени и это позволяет очень быстро увидеть укладывается ли команда в тот темп, который она запланировала. Если вы, например, 2-3 спринта подряд делаете только половину работы из той, что была запланирована на спринт, то можно смело утверждать, что весь проект вы скорее всего уже не уложите в изначальные сроки.  На мой взгляд это очень полезная практика, ведь, как известно,  любой проект длительностью больше 6-9 месяцев быстро становится неуправляемым, а разбиение его на небольшие фрагменты с постоянным контролем результатов позволяет не потерять управление ситуацией. 

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

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

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

Kanban - это отличный инструмент организации конвеерной скажем так работы. Основной отличительной фишкой канбана является так называемый лимит выполняемой работы (WIP limit). Предположим у вас есть некий процесс, предполагающий прохождение по определенным стадиям.  Это может быть обработка инцидентов, обработка запросов на создание учетных записей, обработка заявок на доступ к информационным ресурсам и проч.  Т.е задача (или заявка или что-то еще, далее для простоты я буду говорить "задача") проходит последовательно через несколько этапов, за которые могут отвечать в том числе разные исполнители.  Основной целью в канбане является то, чтобы прохождение задачи по всем стадиям было как можно более быстрым и чтобы не встречало никаких препятствий, т.е чтобы создавался непрерывный поток, основным показателем эффективности которого является среднее время, которое уходит на то, чтобы пройти процесс от начала до конца.  

"А зачем же нужен лимит выполняемой работы ?", спросите вы. Лимит выполняемой работы определяет какое количество задач может одновременно находится на определенной стадии. И если этот лимит достигнут, то никакие новые задачи на эту стадию перейти уже не могут.  Это позволяет очень быстро выявить узкие звенья в процессе, на которых случается "затык".

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

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


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

Приказ ФСБ по ПДн видишь ? А он есть :)

В пятницу по наводке Александра Виноградова заглянул в Консультант и обнаружил там "Приказ ФСБ России от 10.07.2014 N 378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных...".

Сам приказ как можно видеть датирован июлем, зарегистрирован в Минюсте 18 августа.Тем не менее приказ еще не опубликован, а значит еще не вступил в действие.  Другое дело, что как мне кажется, публикация не заставит себя долго ждать.

Что же мы имеем с точки зрения требований:



Критики по приказу уже было высказано немало, лично меня конечно огорчило, что ФСБ предлагает защищать, причем ого-го как защищать системы 4-го уровня, к которым между прочим относятся в том числе ИСПдн, обрабатывающие общедоступную информацию. Зачем спрашивается ?  

Оригинал представленной таблицы можно скачать тут - https://drive.google.com/file/d/0B-diDhbmRj8gQ1BlSHBtTF8xMFE/edit?usp=sharing

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

Англоязычные подкасты по информационной безопасности

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

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

PaulDotCom's Security Weekly - один из самых известных в сети Интернет подкастов, а можно даже сказать и видео-кастов, т.к. автора подкаста Пола Асадориана (Paul Asadorian), а также его команду можно не только слушать но и видеть. Эксперты обсуждают широкий круг вопросов и событий, происходящих в области информационной безопасности и регулярно приглашают себе в студию известных в индустрии людей. 

Risky Business - подкаст от австралийского эксперта по информационной безопасности по имени Патрик Грей (Patrick Gray). Подкаст выходит примерно один раз в неделю и посвящен обсуждению актуальных новостей в индустрии ИБ.

Network Security Podcast - один из старейших подкастов по информационной безопасности от эксперта компании Akamai Мартина МакКея (Martin McKeay). Тематика выпусков самая разнообразная: от обзора происходящих конференций, до разбора громких инцидентов информационной безопасности.

Sophos Security Chet Chat - подкаст от экспертов компании Sophos. В рамках коротких 15-минутных подкастов ведущие обсуждают все актуальные новости, произошедшие за последнюю неделю.  Так что если времени на прослушивание у вас не так много, то это подкаст для вас.

Tenable Network Security Podcast - подкаст от компании - разработчика всемирно известного сканера уязвимостей Nessus. Авторы подкаста обсуждают новости, связанные с развитием продукта компании, а также разбирают выявленные экспертами компании технические уязвимости.

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

До BIS Summit 2014 меньше месяца

Осень, как известно, богата на разного рода мероприятия и вопреки мусируемым слухам о том, что в России осталась только одна отраслевая выставка, посвященная вопросам защиты информации, :) на самом деле еще есть куда сходить и что посмотреть. Ближайшее мероприятие, на котором я планирую быть - BIS Summit 2014. Так что буду рад со всеми встретиться и пообщаться. До скорых встреч.

Ниже краткая информация о мероприятии от организаторов:

------

Конференция, ранее известная как DLP-Russia, под нынешним названием будет проводится впервые. Мы изменили не только название, но и расширили круг рассматриваемых вопросов по информационной безопасности. Темой этого мероприятия стала «ИБ и управление рисками бизнеса».

Почему мы выбрали такую тему?

В условиях экономического кризиса и стагнации задача управления рисками бизнеса становится одной из первостепенных. С точки зрения ИБ борьба с финансовыми потерями начинается с административных издержек и заканчивая производством, складскими запасами, сбытом и пр. От 60 до 70 % издержки возникают либо в результате чьей-то халатности, ленности, незнания или невнимания. Поэтому и возникает вопрос, как автоматизировать бизнес процессы так чтобы своевременно выявлять, предотвращать потери и управлять рисками бизнеса? Давайте вместе постараемся найти ответы на эти вопросы!

Чего ожидать от BIS Summit' 2014?
  • Более 30 докладов международных и российских экспертов
  • Круглые столы, тематические секции, демонстрация новинок ИБ-решений
  • Возможность за 1 день увидеть и узнать все о последних тенденциях в сфере ИБ
Ссылка на полную информацию о конференции здесь: http://bis-expert.ru/bis-summit

----

P.S. Кстати, практически сразу после BIS Summit будет еще одно мероприятие - консультативный семинар «Комментарии к документам Банка России по обеспечению ИБ и защиты информации», спонсором которого выступает компания R-Vision, и на котором я тоже обязательно буду.

четверг, 17 июля 2014 г.

Вебинар: Моделирование угроз, контроль соответствия и управление инцидентами в рамках требований ФСТЭК c R-Vision

Еще есть возможность успеть :) 

Тема вебинара: “Обеспечение соответствия требованиям нормативных документов ФСТЭК с помощью R-Vision”

В рамках вебинара мы рассмотрим следующие вопросы:

1)  Подготовка модели угроз безопасности (для ИСПДн и ГИС)
2)  Контроль выполнения требований приказов ФСТЭК №21 и №17
3)  Управление инцидентами, связанными с информацией, относящейся к ПДн

В том числе я расскажу каким образом решение этих задач может быть автоматизировано с помощью нашей разработки - программного комплекса R-Vision

Начало вебинара 17 июля в 10:00 (т.е через 30 минут)

Регистрация тут - http://rvision.pro/event/152-fz-and-r-vision/

понедельник, 21 апреля 2014 г.

Скрытая и неустранимая угроза (размышления на тему Heartbleed)

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

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

Теперь давайте посмотрим с другой стороны, со стороны разработчика коммерческого программного обеспечения (в т.ч. и средств защиты информации).  Практически никто сейчас не разрабатывает программное обеспечение с нуля в полном вакууме. В любом случае используются какие-то IDE, компиляторы, программные библиотеки, готовые компоненты, базы данных наконец.  Возьмите любую более-менее сложную программную систему (или средство защиты) и вы увидите что в сердце него обязательно есть какая-то база данных (MS SQL, MySQL, Oracle и пр.).    Помните этот вирус, который несколько лет назад наделал много шума среди разработчиков ?  Вредонос заражал компилятор и в итоге все созданные с помощью этого компилятора программы становились носителями вируса. Неплохо ?  Как знать, может быть это были полевые испытания ?

Таким образом мы имеем то, что практически в любой программный код можно встроить скрытую уязвимость (она же закладка) через сторонние компоненты, используемые при его разработке и/или функционировании.   Можно ли от этого защититься ?   Давайте рассмотрим типовые предложения:

1) Использовать только опенсорс ?  Нет, не поможет. Хотя у нас вот уже сколько всего государственного все порываются создать на базе опенсорса (и отечественную ОС и вот теперь вроде как защищенные мобильники для госслужащих  и проч.)  Да только будет ли это действительно безопасно ? История с Heartbleed очень четко показала, что нет. Современные программные компоненты содержат такое количество кода, что никто либо не в состоянии его проанализировать, либо просто не готов тратить на это время / ресурсы и деньги наконец. 

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

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

Я считаю что подобными разработками могут и должны заниматься специально созданные компании (ФГУПы или что-то подобное), причем их разработки должны быть предназначены в первую очередь для военных целей (включая вопросы защиты гостайны и проч.). Такие компании за счет финансирования государства смогут себе позволить вести разработки с нуля. Более того они могли бы привлекать к этим разработкам существующие в России ВУЗы, обучающие по направлению информационной безопасности, прикладной математики, программирования. Т.е получится что-то вроде военных заводов, если проводить аналогию с разработкой оружия, только по производству программного обеспечения. При этом результат их разработки можно будет продавать и коммерческим структурам, которые посчитают для себя угрозу внедрения скрытых уязвимостей / закладок недопустимой и требующей минимизации.  Вот куда лучше потратить деньги, а не на переделку под защиту гостайны очередной модификации Android или Linux. Но это если конечно мы хотим добиться реального результата, а не просто освоить бюджет. 

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

четверг, 10 апреля 2014 г.

Занимательная статистика анализа зарубежной литературы

Чисто случайно наткнулся на интересный сервис от компании Google под названием Google Books Ngram Viewer. Смысл сервиса заключается в том, что он позволяет получить статистику упоминания любых слов (терминов, имен, названий и проч.) в литературе, которую уже успела оцифровать корпорация добра. Литература представлена чуть ли не с 1500 годов н.э. и при этом на разных языках (понятно что бОльшую часть занимает английская литература).  Вот я и решил попробовать посмотреть на развитие определенных трендов в ИБ на базе анализа литературы. Ведь чем популярнее становится тема в профессиональном сообществе, тем активнее она начинает проявляться в виде каких-то книжек.

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

Вот статистика по термину "27001"
Как можно увидеть наибольший всплеск интереса к теме ISO 27001 пришелся на период 2005-2006 гг.

А вот статистика по термину "Information security management" показывает уверенный рост:
Ступенчато, но все же по восходящей идет статистика и по термину "information security risk management"
Термин "data leakage", кстати тоже показывает устойчивый рост, хотя и не такой резкий, как представленные выше
Тоже самое можно сказать про термин "Compliance" Такая вот занимательная статистика.

среда, 12 марта 2014 г.

Облачным провайдерам на заметку

Если взять любое исследование, в котором рассматриваются причины, по которым организации не торопятся переводить свою ИТ-инфраструктуру в облака (несмотря на все плюсы, которые это может сулить), то на первом месте мы там увидим, конечно же, "безопасность". Точнее опасение о снижении ее уровня в случае перехода. 

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

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

Сразу оговорюсь, что под "облачным сервисом" я пониманию в данном случае только SaaS-сервисы.

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

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

3) API для интеграции со средствами защиты. Раз уж мы заговорили про API, то опять же в "правильном" сервисе должна быть возможность подключить к облачной системе различные механизмы защиты, которые могут обеспечить выявление подозрительных действий, антивирусную проверку, контроль конфигурации, аудит правил доступа и многое другое.  В противном случае получается, что компании, потратившие огромные деньги на приобретение разного рода средств защиты, оказываются беспомощны перед облачными системами, не допускающими никакой интеграции и внешнего контроля.

4) Логи, и еще раз логи.  Журналы работы системы - это один из важнейших источников для оперативного выявления событий, которые могут негативно отразиться на деятельности организации, а также сбора необходимой базы для проведения расследования и юридического преследования возможных виновников. Предоставляет ли ваш провайдер логи работы системы (пусть даже только применительно к вашему экземпляру системы) ? Есть ли возможность отправить эти логи в SIEM-систему, чтобы обеспечить централизованный мониторинг и хранение информации ?  Боюсь что в большинстве случаев ответ на эти вопросы будет - "нет".  А ведь без этого вы вообще никак не контролируете что происходит в системе.

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

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

понедельник, 3 марта 2014 г.

О проведении конференций на примере Уральского форума

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

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

Ну а теперь по пунктам:

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

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

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

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

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

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

На PHD, кстати, я несколько раз попадал на доклады, не связанные с хакингом и подобными темами, и зал был полон.

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

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

пятница, 28 февраля 2014 г.

Февральский номер журнала (IN)SECURE

Качаем и читаем....свежак :)

Содержание:
  • Cloud insecurity? Time to bust the myth
  • Executive hot seat: Cloud Security Alliance CEO
  • Security uncertainty in the cloud: Problems and potential solutions
  • Share with the world: Who reads my data in the cloud?
  • Executive hot seat: Intrinsic-ID CEO
  • Privacy in the cloud: The power of encryption
  • How to recover deleted or corrupted digital currency
  • Leveraging Big Data for security operations
  • The past, present, and future of Big Data security
  • Information stewardship: Avoiding data breaches and managing Big Data
  • Generating value from Big Data analytics
  • Too big to fail: The Big Data dilemma
Ссылка: https://www.net-security.org/dl/insecure/INSECURE-Mag-41.pdf

пятница, 14 февраля 2014 г.

Ищем талантливых студентов

Нам (как впрочем и всем наверное) нужны талантливые и энергичные ребята. Для начала на краткосрочную практику, а там посмотрим. 

Подробности тут - http://ismsys.blogspot.ru/2014/02/blog-post.html


пятница, 7 февраля 2014 г.

Первая неделя в новом статусе

Всем привет !  Завершаю свою первую неделю в новом статусе.

31 января я покинул компанию LETA, в которой проработал без малого 7 лет. Сделал я это для того, чтобы все свои силы направить на развитие пока еще молодого для российского ИБ-рынка проекта - R-Vision.

У проекта масса идей, на этот год запланировано много интересного, в том числе и для широкой экспертной аудитории, так что следите за анонсами в моем блоге :), а также в блоге проекта - ismsys.blogspot.com

Если есть интересные темы, то я открыт к общению, мои контакты:

LinkedIn - http://ru.linkedin.com/in/alexbondarenko
Facebook - https://www.facebook.com/alexander.bondarenko.754
Twitter - https://twitter.com/AlexBondarenko

Если будет желание встретиться очно, то в ближайшее время я планирую посетить:

Форум Технологии Безопасности - в среду 12 февраля там планируются выступления коллег из ФСТЭК на животрепещущие темы.

VI Уральский Форум ИБ Банков - ну тут даже комментировать нечего, одно из крупнейших мероприятий отрасли и отличная возможность пообщаться в неформальной обстановке. 

пятница, 17 января 2014 г.

План проверок Роскомнадзора по линии персональных данных на 2014 год

Пятница - отличный день чтобы что-то начать (или возобновить) :) 

Всем привет !  Давно ничего я сюда не писал, но я никуда не делся, просто стало катастрофически не хватать времени.  

Мне кажется пока еще никто не выкладывал, хотя сам план проверок уже некоторое время доступен на сайте РКН.  Слава богу, что теперь эти планы выкладываются в виде doc-файлов, а не сканированных картинок. Похоже здравый разум побеждает и это радует. 

А на сайте 152pro.ru план проверок, содержащий данные только по проверкам по линии ПДн,  доступен в виде веб-страницы, по которой можно быстро сделать поиск и узнать, доведется ли вам в конце года делится с коллегами опытом проверки по части персональных данных :) 

Всем отличного настроения и до новых (как я надеюсь скорых) встреч.