пятница, 11 ноября 2016 г.

Тяжела жизнь стартапа

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

В этом году, кстати, конкурс проходит снова и еще есть несколько дней, чтобы подать свою заявку (https://sk.ru/foundation/events/august2016/cyber2016/).  

Я решил попробовать проследить судьбу проектов, участвовавших в конкурсе в прошлом году. 

Тройка победителей

№ 1 (Первое место) 

IP PIER — система защиты от DDoS атак на сетевом уровне, так и от DDoS атак на уровне приложений;
(x) Сайта у проекта нет. За последние 6 месяцев не найдено ни одного упоминания в сети Интернет, связанного с этим проектом. Проект как самостоятельный стартап скорее всего мертв, технологии (возможно) стали частью других продуктов (возможно используются тут - https://www.skyparkcdn.ru). 

№2 (Второе место)

AwareDefense — система контроля качества защиты организации от целевыхкибер-атак;
(=) У проекта есть сайт (http://www.awaredefense.com/), но при этом не найдено никаких упоминаний за последние 6 мес. Судя по сайту проект все еще в стадии бета, в общем и целом проект выглядит застывшим. 

№3 (Третье место) 

AutoVisor - комплекс мониторинга и выявления угроз информационной безопасности бортовых автомобильных систем;
(x) У проекта нет сайта, не удалось найти никаких упоминаний в сети Интернет, связанных с этим проектом. Проект скорее всего мертв, единственный материал, найденный в Интернет, ведет на сайт компании НСБ (http://newsb.ru/)

---

Ну и все остальные: 

«СайтСекьюр» — облачный сервис защиты сайтов от потерь и простоев, вызванных интернет-угрозами. Сервис мониторинга безопасности сайта избавляет от проблем с вирусами, хакерами и обеспечивает работу бизнеса без потерь и простоев;
(!) Сайт проекта: https://sitesecure.ru/. Проект развивается, недавно привлек инвестиции от фонда ФРИИ. 

Factod — сервис для разработчиков по защите мобильных приложений с помощью IoT- и wearable-устройств;
(x) Никаких сведений о проекте найти не удалось. 

Dynamic Web — паутина динамических ключей;
(x) Никаких сведений о проекте найти не удалось. 

Limbo-couб — проактивная cистема обеспечения информационной безопасности Limbo обеспечивает интегрированную защиты от мультивекторных угроз, включающих кампании АРТ-класса, современное вредоносное ПО и атаки, эксплуатирующие уязвимости «нулевого дня»;
(x) Никаких сведений о проекте найти не удалось. 

Data-driven intelligent framework — интеллектуальная платформа обеспечения безопасности информации и управления событиями в больших сетях.
(x) Никаких сведений о проекте найти не удалось. 

«Безопасный интернет вещей» — универсальное и безопасное решение вопроса подключения Вещей к Интернету, посредством Controlled-UWB RF-технологии, обеспечивающей криптозащиту структуры радио-сигнала;
(x) Никаких сведений о проекте найти не удалось. 

R-Vision — программный комплекс автоматизированного контроля и мониторинга за состоянием информационной безопасности организации и поддержки специалистов в принятии решений по комплексной защите информации организации от компьютерных угроз;
(!) Проект активно развивается, подробности можно читать в этом блоге, а также на сайте компании. Сайт: http://rvision.pro


Вот такая вот занимательная статистика. 

P.S. Если меня читает кто-то из основателей этих проектов и вы нашли здесь неточности, смело пишите в комментариях к этому посту.

P.P.S В этом году Команда R-Vision участие в конкурсе принимать не планирует. 

среда, 9 ноября 2016 г.

Поговорим о реагировании на инциденты

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

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

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

К чему я все это ?  А к тому что мы в команде R-Vision за последнее время провели немалую работу и готовы представить вам платформу R-Vision Incident Response Platform, которая предназначена как раз для повышения эффективности команды реагирования и координации всей деятельности по обработке инцидентов информационной безопасности. 

Хотите узнать подробности ?   Подключайтесь к вебинару - 


И обязательно приходите к нам на стенд на SOC-Forum v2.0. 

вторник, 8 ноября 2016 г.

А виноваты во всем будут.....хакеры

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

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

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

P.S. Поверить в целенаправленный взлом и манипуляцию можно будет пожалуй только если в выборах победит В.Путин :) 

вторник, 1 ноября 2016 г.

Не пора ли начать активнее обмениваться информацией ?

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

А есть ли что-то подобное на светлой стороне силы ?  Ну не густо, скажем прямо. Куда податься за советом безопаснику ? 
  • Форум безопасников на bankir.ru. Есть полезные дискуссии, но конечно же большая часть относится чисто к банковской сфере и в основном обсуждают вопросы, связанные с соблюдением требований. 
  • Сообщество RISSPA в LinkedIn. Это конечно не единственная дискуссионная группа, но, пожалуй, единственная более-менее живая. 
  • Форум SecurityLab. Форум с техническим уклоном, тут много про уязвимости, хакинг, кодинг и проч.
Вот наверное и все площадки. Да, есть какие-то еще форумы, но в большинстве там все уныло. Я возможно о каких-то площадках не в курсе, напишите в комментариях, если знаете еще что-то стоящее.  

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

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

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

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

Как быть ?  Вопросов больше чем ответов.  Чем не повод для дискуссии на SOC Forum 2016

До встречи на мероприятии и успехов в нелегком труде по отражению атак кибер-преступников !

среда, 12 октября 2016 г.

Выбираем SIEM. ТОП-10 ключевых критериев

Хочу продолжить тему выбора средств защиты, начатую в прошлом посте, и поговорить адресно про популярные нынче SIEM-ы. Нужен вам на самом деле SIEM или нет я обсуждать не буду, допустим, вы решили что нужен. Как выбрать ? Как сравнить имеющиеся решения ? Нужна видимо какая-то система критериев.  

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

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

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

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

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

5. Легкость интеграции / разработки новых коннекторов. Коннекторы однозначно потребуются, не сразу так потом. Поэтому лучше сразу понять уровень сложности этой задачи. Можно ли это сделать самому или обязательно потребуется привлекать вендора / интегратора. Насколько легко и интуитивно это можно сделать или необходимо будет освоить серьезные программерские навыки. 

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

7. Удобство / легкость настройки и работы с системой. Субъективный критерий, но легко проверяется на пилоте. Если интерфейс кривой-косой, не интуитивный, непонятный, то работать с системой будет сложно. В этом смысле самый правильный путь это в рамках пилота дать поработать с системой тем, кто в боевом режиме будет с ней работать, и потом попросить их оценить удобство работы с системой по одному или нескольким субъективным критериям: эргономика, понятность, удобство (провести мини-анкетирование или просто коллективное обсуждение).

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

9. Гибкость настройки правил корреляции. Одна из ключевых задач SIEM-а это корреляция.  Ради этого многие и берут это решение. Но без правил корреляция не работает, а значит эти правила надо будет писать. Готовые правила конечно есть у большинства разработчиков, но они как правило добавлены только для того чтобы можно было показать в качестве демо-примера, в реальной жизни они вам скорее всего не понадобятся, нужно будет писать свои. И вот тут как раз и возникнет вопрос того насколько это все легко и просто, в общем, все очень похоже на п.5.

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

среда, 5 октября 2016 г.

Итак, вы решили прикупить себе еще средств защиты

К сожалению из-за технических неполадок не удалось выступить на BIS Summit в формате "открытый микрофон", поэтому решил написать сюда те мысли, которые хотел изложить. 

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

Наверное многие из вас сразу подумали про демо/ пилот. А вот и нет. Первым делом надо бы вообще понять кто есть в этой области, какие решения, какие производители, какие есть потенциальные аналоги или заменители.  А с этим все значительно хуже. В свое время мы в рамках своей работы создали ISM:Market, но сил на развитие проекта не хватило, он все еще доступен онлайн, но не обновлялся уже года 3, так что не судите строго. Тем не менее.

Квадранты Гартнера / Волны Форрестера. Как бы кто к ним не относился, но на них обращают внимание крупные компании и все же совсем левых игроков в отчетах Gartner и Forrester нет, если решение/производитель в отчете значит оно как минимум стоит вашего внимания. Гартнер покрывает конечно не все области, вот тут можно найти мою заметку про то что у них есть.  Отчеты как правило нельзя скачать просто так с сайта Гартнера или Форрестера, но всегда есть производители, которые, заняв хорошее место, хотят этим похвалиться, и раздают на своих сайтах отчеты в обмен на email. А у Gartner еще недавно появился Gartner PeerInsights - сайт, на котором можно почитать отзывы о тех или иных решениях.

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

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

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

Пилот с критериями. Ну и наконец, конечно же, пилот. Но только пилот лучше всего проводить, составив предварительно набор критериев, по которым будет оцениваться решение. Кейс на моей памяти: одна крупная компания решила сменить свой корпоративный антивирус, дело это серьезное, поэтому коллеги совместно с подразделением ИТ сформировали довольно длинную табличку критериев, которым в идеале должно соответствовать выбранное решение. После этого последовательно пропилотировали 3х антивирусных производителей и остановили выбор на том, которое максимально близко приблизилось к полному соответствию заданным критериям (на 100% не соответствовало ни одно). 

Успехов вам ! 

четверг, 22 сентября 2016 г.

IRP - недостающий компонент корпоративного SOC-а ?

В преддверии SOC-Форума и прям накануне BIS Summit хочется снова поговорить о том, что же такое SOC :)  А точнее о его составляющих.  

Вроде в прошлом году все говорили о том, что SOC это не SIEM, это люди, технологии и процессы. И вот в процессе этих дискуссий лично у меня было такое ощущение, что как-будто чего-то не хватало.   

А не хватало того самого компонента, который многие пытаются реализовать на сервис-десках, в джире и прочих системах. Т.е он есть практически всегда (или о нем задумываются), но почему-то о нем практически не говорят. Это то что Gartner назвал Incident Response Platform. 

Может настало время поговорить ?  



пятница, 16 сентября 2016 г.

Технологическая сингулярность в информационной безопасности

Герман Оскарович Греф в последнее время все чаще подкидывает поводы для рассуждений. Вот на прошлой неделе он заявил, что всего через 5 лет в Сбербанке 80% решений будет приниматься без участия человека. Журналисты в этом, конечно же, в первую очередь ухватили тот момент, что при этом 20 тысяч человек лишатся своей работы. 

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

Вот и Евгений Касперский на эту тему недавно высказался, что мол искусственный интеллект развивается. Но я честно говоря пока никаких особых прорывов в этой области не наблюдаю. Про big data в безопасности говорят много, а SIEM-ы как работали 10 лет на правилах, которые люди должны написать, так и работают.  Практически все имеющиеся средства защиты (за исключением антивирусных технологий и ряда других специфических продуктов) практически не обладают в себе никакими компонентами самообучения и автоматизации принятия решений. 

Ну ок, понятно что требовать подобное прямо сейчас было бы неправильно, тема AI только развивается, но слышали ли вы о каких-либо планах ведущих ИБ-разработчиков в этой области ? Может конечно все это просто скрывают :) 

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

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

P.S. Коллеги, если вы следили за кибербаталиями и вам понравился мой бой с Эльманом, то проголосуйте за мою кандидатуру на приз зрительских симпатий  - http://www.infowatch.ru/cyberfight2016

P.P.S  А еще в тему автоматизации на следующей неделе 22 сентября, как раз накануне BIS Summit, мы проводим вебинар по управлению уязвимостями совместно с коллегами из проекта Vulners. Будем рады вас всех видеть - https://rvision.pro/?post_type=event&p=1408


четверг, 8 сентября 2016 г.

Квадранты Гартнера в ИБ

Кто бы как ни относился к квадрантам Gartner-a, а все же на них обращают внимание, даже у нас в России. Я уже не говорю про западные страны, где серьезный корпоратив однозначно смотрит на тех, кто в лидерах.

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

Я тут выписал все квадранты, которые есть на тему ИБ:
  • Business Continuity Management Planning Software Worldwide 
  • Endpoint Protection Platforms 
  • Enterprise Data Loss Prevention 
  • Enterprise Mobility Management Suites 
  • Enterprise Network Firewalls 
  • Identity Governance and Administration 
  • Intrusion Prevention Systems 
  • IT Risk Management Solutions 
  • IT Vendor Risk Management 
  • Operational Risk Management Solutions 
  • Secure Email Gateways 
  • Secure Web Gateways 
  • Security Information and Event Management 
  • Unified Threat Management Worldwide 
  • Web Application Firewalls
Сделаю оговорку, я исключил квадранты по сервисам, MSSP и подобным вещам.  

Кстати, полный список квадрантов с датами публикаций и планами по ревью можно посмотреть на официальном сайте, тут:

http://www.gartner.com/imagesrv/research/methodologies/publication_calendar.xlsx

P.S. А еще, о чем возможно немногие слышали, некоторое время назад Gartner запустил свою площадку для отзывов о продуктах. Называется Gartner peerinsights. Пока там не так много отзывов, но ведь все только начинается. 

среда, 31 августа 2016 г.

Интерфейсы взаимодействия у средств защиты

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

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

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

четверг, 25 августа 2016 г.

Agile - новое слово в ИБ ?

Тема Agile с легкой руки Германа Грефа активно пошла в народ. Все вдруг неожиданно заговорили про необходимость реализации гибких подходов, причем во всем. За последнее время я слышал про agile и в контексте управления всей компанией и в кадровых процессах и в ..ИБ...

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


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

Давайте посмотрим что же такое agile и как он может быть реализован в ИБ. Эта идеология строится всего на 4 основных постулатах:
  • Люди и взаимодействие важнее процессов и инструментов. ИБ обеспечивают люди, работать приходится с людьми, люди самое слабое звено в безопасности и т.п. Поэтому конечно же этот постулат применим к ИБ и его можно также интерпретировать как то, что прежде чем покупать очередную дорогую игрушку (DLP, SIEM и проч.) нужно понять каким образом текущие коммуникации и деятельность людей будет улучшена / автоматизирована / оптимизирована, т.к первоочередными являются именно они, а не средства их обеспечения. 
  • Работающий продукт важнее исчерпывающей документации. Вроде все верно, внедренные и эффективно работающие средства защиты и процессы обеспечения безопасности важнее тонны написанной бумаги (получите, бумажные безопасники!). Но есть, конечно же, ньюансы. Если вы часто общаетесь с регуляторами, то знаете что для них бумага важнее, что далеко ходить, даже в СТО БР или 382-П математика оценки соответствия составлена так, что если у вас нет документов, то получите 0 и претензии со стороны регулятора. Поэтому если не вдаваться в крайности этот постулат можно интерпретировать как то, что актуализация документации, ее 100% соответствие текущей реальности по приоритетам должна быть ниже чем актуализация и совершенствование сами средств защиты и процессов.
  • Сотрудничество с заказчиком важнее согласования условий контракта. Заказчиком в данной ситуации выступает бизнес / руководство / собственники. Данный постулат говорит о необходимости выстраивания неформальных взаимоотношений, позволяющих получать быструю и конструктивную обратную связь, обеспечивающих возможность оперативного согласования и корректировки в условиях постоянно меняющихся внешних обстоятельств. В общем, меньше формализма и действий строго по должностной инструкции, а больше конструктива, сотрудничества и работы на конечный результат.
  • Готовность к изменениям важнее следования первоначальному плану. Любой план не более чем ориентир. Жизнь постоянно меняется и вы должны быть готовы меняться что называется "на ходу". Этот постулат требует довольно серьезной, фундаментальной перестройки. Вы сами, ваша команда, внедряемые вами практики и механизмы, реализуемые вами проекты, все это должно создаваться и развиваться в идеологии готовности к любым изменениям в любой момент. Тут очень непростым окажется вопрос взаимодействия с внешними подрядчиками. Не даром же на любые работы или системы изначально пишется ТЗ, в соответствии с которыми они реализуются. Так что возможность постоянно менять условия и требования для внешних подрядчиков выльется в дополнительные расходы, хотя, возможно, позволит избежать еще больших и, что самое важное, совершенно неэфффективных трат.  
Вообще тема agile очень большая и в один пост все не уложишь.  Кому интересна тематика советую сходить на конференцию AgileDays, но сразу оговорю что это мероприятие, ориентированное в первую очередь на разработчиков и тех, кто управляет разработкой. Но как знать, может быть какие-то идеи из смежных областей вы сможете с успехом перенести в ИБ. Успехов ! 

пятница, 29 января 2016 г.

Ищем консультанта в команду R-Vision

Всем привет !  Давно ничего не писал, прошлый год заканчивался динамично, новый начался не менее бодро. 

Мы растем, ставим перед собой новые цели и задачи, о многом хочется рассказать, но пока возьму паузу, чтобы не спугнуть удачу :)    Пост собственно не об этом, а о том, что мы ищем единомышленника в команду.  Хочешь вместе с нами покорить мир ? Присоединяйся ! 

Нам нужен консультант по информационной безопасности, в круг задач, которого будет входить:
  • Консалтинг и помощь заказчикам компании в реализации лучших практик в области менеджмента информационной безопасности. 
  • Разработка рекомендаций по совершенствованию процессов менеджмента информационной безопасности. 
  • Общение с потенциальными клиентами компании на этапе пресейла совместно с менеджерами по продажам. 
  • Проведение периодических обучений клиентов по тематикам в области менеджмента информационной безопасности. 
  • Разработка политик, методик и иной документации по информационной безопасности. 
  • Участие в разработке методических материалов, справочных публикаций, статей и другого специализированного материала как для широкой аудитории, так и для внутреннего использования. 
  • Участие в работе различных рабочих групп, ассоциаций, комитетов и пр. в качестве представителя компании.
Более подробно есть тут -  http://kotelniki.hh.ru/vacancy/15836320

Заинтересовала вакансия ? Пиши нам на адрес hr@rvision.pro

пятница, 6 ноября 2015 г.

Ключевые факторы в деятельности по реагированию на инциденты ИБ

В преддверии SOC-форума, решил высказаться по сабжу. 

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

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

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

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

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

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

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

Как видите все вышеперечисленное не про технические системы. SIEMы, IDSы, и проч. всего лишь инструменты, которые должны помочь реализовать стоящие перед группой реагирования на инциденты ИБ задачи и помочь с тем что я описал. К сожалению плохие, непродуманные внедрения порой становятся главным препятствием на пути к нормальному инцидент-менеджменту. 

P.S. На SOC-форуме я буду вместе с моими коллегами представлять проект R-Vision. Подходите, буду рад пообщаться. 

P.P.S. Что касается инструментов, то на следующий день после SOC-форума буду проводить вебинар с демонстрацией новых возможностей R·Vision SGRC по управлению инцидентами ИБ. Регистрация тут - https://rvision.pro/?post_type=event&p=1219

среда, 28 октября 2015 г.

Оценка рисков с использованием R·Vision SGRC

Всем привет ! 

Завтра провожу вебинар по теме "Оценка рисков с использованием R·Vision SGRC"


Поговорим про анализ рисков вообще и моделирование угроз в частности, обсудим западные методики и пока еще не вышедшую методичку ФСТЭК.  Детально расскажу и покажу новые возможности по идентификации и оценке рисков в R·Vision SGRC. 

Регистрируйтесь, вебинар завтра, 29 октября в 11:00 ! 

вторник, 20 октября 2015 г.

Организация программы по повышению осведомленности

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

Одним из самых недорогих, но действенных методов по повышению общего уровня безопасности на мой взгляд является программа повышения персонала в вопросах ИБ. Внедряя такую программу в компании подразделение ИБ убивает сразу 2х зайцев:
  • сотрудники становятся более грамотными в плане ИБ, что приводит к меньшему количеству ошибок, обращений в ИТ и ИБ и в конечном итоге уменьшает количество инцидентов;
  • программа повышения осведомленности может помочь популяризировать деятельность подразделения ИБ в компании, эдакий способ PR-а внутри компании. 
Есть несколько простых инструментов, которые могут составить такую программу повышения осведомленности: 
  • периодические тренинги персонала - самый очевидный, но при этом самый ресурсозатратный метод, да и часто вызывает определенное отторжение, поэтому я бы рекомендовал его применять крайне дозированно (раз в год, например). 
  • рассылки внутри компании - метод простой и в меньшей степени напряжный, особенно если удастся обеспечить хороший контент для такой рассылки. Если делать ее не часто (раз в месяц например) и включать советы в том числе по личной компьютерной безопасности, то уверен что найдется немало людей кто будет даже благодарен. 
  • плакаты, наглядная агитация - хороший метод, но только если прям угадаете с оформлением. Нужно ориентироваться на принятую культуру в компании, средний возраст персонала и проч. Должно быть интересно, немного смешно и должно запомниться.  Есть вечные темы вроде полуголых женщин, призывающих "не болтать", есть дизайнерские находки, вроде тех плакатов, которые в свое время делал для себя Билайн (жаль что их нигде в сети нет)
  • база знаний - раздел на внутрикорпоративном сайте компании, который содержит в простой и доступной форме описание и разъяснение основных положений политики ИБ компании, описание действий в ситуации "если вдруг ___  то действуйте так ____"
Для реализации всего того, что я написал выше, в первую очередь нужен грамотный контент - материал из которого будут делаться тренинги, рассылки, плакаты и проч.  С этим конечно все сложнее и это пожалуй единственный серьезный барьер, о который разбиваются многие попытки внедрить деятельность по повышению осведомленности. 

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

  • Проект Так безопасно от компании ЛЕТА - набор готовых плакатов - скринсейверов, с описанием стандартных и очевидных правил информационной безопасности.
  • Microsoft Security Awareness Toolkit - тулкит от компании Microsoft, содержащий различные материалы (планы, статьи, презентации), которые могут быть использованы для реализации программы повышения осведомленности. 
  • Stay Smart Online - Сайт Австралийского агентства Department of Communications and the Arts, содержит набор статей, описывающих основные рекомендации по обеспечению персональной безопасности в сети.  
  • Stop. Think. Connect - онлайн ресурс, содержащий рекомендации по обеспечению ИБ, а также подборку плакатов