23.11.2015

Впечатления от межбанковской конференции по ИБ в Казахстане

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


Я не буду подробно останавливаться на всех прозвучавших докладах, тезисно коснусь только запомнившихся мне выступлений и тем:

  • Нацбанк Казахстана к 2017-му году планирует пройти сертификацию на соответствие стандарту 27001. Правда, не было озвучено какой из процессов будет подан на сертификацию. Но все равно, амбициозный проект. Вслед за Нацбанком, могу предположить, потянутся и другие банки, для которых национальный регулятор станет примером и ориентиром.
  • Нацбанк, признавая устаревание действующих документов по ИБ, сейчас пересматривает всю свою нормативную базу в этой области.
  • Помимо обновления собственных документов, Нацбанк предпринимает ряд шагов по улучшению уровня защищенности казахстанских банков. Особенно интересно среди них выглядит переход на сервисную модель ИБ, учитывающую лучший мировой опыт и такие практики как ISO 9001, ISO 20000 (ITILv3), ISO 27001 и ISO 21500 (PMBOK). 
  • Помимо этого Нацбанк Казахстана подготовил ряд законопроектов, которые похожи на то, что в свое время затевал наш Банк России в связи с законом "О национальной платежной системе". В частности в законе о Нацбанке устанавливаются полномочия об установлении требований по ИБ для казахстанских банков. Банки обязаны обеспечивать бесперебойность осуществления своих операций (в законопроекте это называется беспрерывность). И банки будут обязаны направлять в Нацбанк информацию о мошеннических действиях в ДБО. 
  • Как и его российский "коллега", казахстанский Нацбанк планирует создать собственный центр реагирования на компьютерные инциденты (CERT), в который будет стекаться вся информация об инцидентах от банков и правоохранительных органов. В Казахстане уже действует свой CERT.KZ (некий аналог ФСБшного GOV-CERT.RU), о деятельности которого также рассказывалось на конференции. С ним должен интегрироваться и создаваемый Нацбанком центр реагирования.

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

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

20.11.2015

Как оценить эффективность SOC?

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

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

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


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


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

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

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


Если SOC среди услуг по реагированию на инциденты предлагает функции реконфигурации средств защиты, сетевого оборудования, ОС, СУБД и т.п., то их можно оценивать следующим образом:

  • Число авторизованных изменений в неделю
  • Число актуальных изменений, сделанных за неделю
  • Число несанкционированных изменений, сделанных в обход утвержденного процесса внесений изменений (в среднем - 30-50%; у лидеров - менее 1% от общего числа изменений)
  • Показатель (коэффициент) неудачных изменений, вычисляемый как отношение несанкционированных изменений к актуальным
  • Число срочных изменений
  • Процент времени, затрачиваемого на незапланированную работу (в среднем - 35-45%; у лидеров - менее 5% от общего числа изменений)
  • Число необъяснимых изменений (вообще, это основной индикатор уровня проблем в данной сфере).

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

В заключение приведу еще один набор метрик оценки эффективности SOC, которые предлагает HP в рамках предоставления своих услуг. Местами спорные метрики, но если они устраивают все стороны (и заказчиков, и поставщиков), то почему бы и нет?..


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

19.11.2015

Экономика SOC или то, о чем на SOC Forum так и не поговорили

Вот про что на SOC Forum почти не говорили, так это об экономике центров мониторинга и реагирования на инциденты. Хотя эта тема очень тесно переплетена с вчера мной рассмотренной про дилемму выбора между собственным и аутсорсинговым SOCом. Вот ею мы и поставим точку в этой долгой эпопее под названием Security Operations Center. Хотя, скорее всего, это будет многоточие...

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

От чего зависит этот бюджет? Как минимум от трех факторов:
  • Собственный или внешний SOC
  • Сервисы, предоставляемые SOCом
  • Время работы SOC (5 х 8 или 24 х 7).
При этом сами статьи затрат меняются не сильно. Просто в случае собственного или аутсорсингового SOCа значения отдельных статей затрат будет нулевыми. Соответственно, часть из этих затрат будут одноразовыми и понадобятся только при создании SOC или заказе соответствующих услуг, а часть будут постоянными или требуемыми время от времени, но точно не одноразовыми. Итак, сходу приходят в голову следующие статьи затрат:
  • Программное обеспечение
    • SIEM и поддержка на него
    • Дополнительный инструментарий и поддержка на него (зависит от сервисов)
    • Коннекторы и поддержка на них
    • Разработка специфических коннекторов
    • Разработка дополнительного инструментария
    • Средства защиты самого SOC
    • ПО Service Desk
    • Разработка портала/сайта/раздела и поддержание его
  • Аппаратное обеспечение
    • Сервера под SIEM, дополнительный инструментарий и Service Desk и поддержка на него
    • Рабочие станции аналитиков и поддержка на них
    • Оборудование для проведения расследований и поддержка на него
    • Источники бесперебойного питания и поддержка на них
  • Хранилище данных
    • Сервера и сетевая инфраструктура под основное хранилище
    • Резервное хранилище
    • Носители информации
  • Услуги
    • Внедрение SIEM и дополнительного инструментария
    • Подписка на источники Threat Intelligence
    • Поддержка инфраструктуры (резервирование, обновление ПО, управление патчами, защита и т.п.)
    • Услуги центров компетенций / внешних консультантов
    • Услуги внешних SOC
    • Аттестация / сертификация / другой compliance (ФЗ-152, СТО БР ИББС и др.)
  • Помещение
    • Физическая безопасность (видеонаблюдение, замки, сейф, шредер, ВОХР/ЧОП и т.п.)
    • Плазмы для визуализации
    • Телефония
    • Электричество
    • Аренда помещения
    • Услуги связи
    • Резервный канал связи
    • Комната отдыха
    • Поддержка в адекватном состоянии (вентиляция, уборка и т.п.)
  • Люди
    • Группа аналитиков и инженеров
    • Группа реагирования на инциденты
    • Группа проведения расследований
    • Обучение персонала SOC
    • Командировки на место инцидента
  • Разное
      • Разработка регламентов.
     Дальше все "просто". В зависимости от ваших задач и ресурсов вы осмечиваете каждую из статей затрат и сравниваете "итого". При этом делать это стоит в некоторой среднесрочной перспективе. Очевидно, что в первый год свой собственный SOC потребует немалых капитальных затрат. Поэтому его выгода по сравнению с аутсорсингом будет видна только через несколько лет (и то не всегда).

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

    18.11.2015

    Свой SOC или аутсорсинговый? А может быть государственный?

    На SOC Forum Олеся Шелестова в своей второй презентации должна была привести некоторые интересные цифры, до которых, она к сожалению, не до дошла, потратив все время на демонстрацию своего решения. А цифры были достаточно интересные и я позволю себе их привести. Только один источник для SIEM/SOC обладает следующими временными характеристиками:

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

    В одной из прошлых заметок я приводил статистику Cisco и Symantec по числу используемых в одной организации средств защиты различных вендоров - от 54 до 75. У того же JSOC 82 разных системы ИБ в эксплуатации. И это только средств защиты, которые могут быть разбросаны по всей сети не в единственном экземпляре. То есть источников, с которых можно брать данные для анализа и реагирования может быть ооооочень много (посмотрите, как пример, на Cisco). Будете ли вы вручную анализировать эти события? Вопрос “а зачем это все анализировать вообще?” я оставлю за рамками сегодняшней заметки; как и вопрос “что делать, если SOC не показывает ни одного инцидента?”. Вроде бы как становится понятно, что нечто для мониторинга нам нужно.

    Будет ли это SIEM или SOC - не суть важно; с терминами все равно полная неразбериха. Например, представители “Перспективного мониторинга” считают, что настроенный и поддерживаемый SIEM, сопровождаемый регламентами реагирования на инциденты, - это и есть SOC. А вот в презентации “Инфосистемы Джет” SIEM рассматривается только как один из инструментов SOC, который выполняет гораздо больше функций, которые не все могут покрыты даже самым разрекламированным SIEMом. Ну да и фиг с ним. SOC, SIEM, CERT, СОПКА… Примем как аксиому, что нечто для мониторинга и реагирования нам нужно. Вопрос в другом. Нам нужен свой SOC (будем его для краткости называть так) или аутсорсинговый? Или вообще понадеяться на государственный (FinCERT и ГосСОПКА)? Ситуацию с запретом на внешний SOC по требованиям регулятора я не рассматриваю. Исходим из того, что мы стоим на распутье - свой или чужой?

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

    • У вас есть сотрудники, обладающие компетенциями и знаниями для работы в своем SOC?
    • У вас есть ресурсы для разработки архитектуры, документов и процессов своего SOC?

    Если на оба вопроса ответ отрицательный, это еще не значит, что вам надо бросать эту затею и идти за помощью к внешнему поставщику услуг. Не случайно тот же Positive Technologies на SOC Forum вышел с идеей внешнего центра компетенций (PT ESC), который может взять на себя часть задач как у аутсорсинговых SOCов, так и у собственных, не обладающих еще полным набором компетенций и знаний. Денег они, конечно, вам не дадут, но экспертизой поделятся.

    Но не стоит думать, что я подвожу вас к мысли об аутсорсинге SOC. Это не так. В каждом случае это выбор делается только вами и на основе ваших текущих исходных данных и планов развития. С внешними аутсорсинговыми SOCа (и тем же центром компетенций PT ESC) тоже не все так просто и очевидно. Поэтому вам стоит задаться такими вопросами:

    • А как будете оценивать квалификацию внешнего SOC и компетенцию его сотрудников? А какова ротация кадров во внешнем SOC?
    • А SOC может вам предоставить копию своих регламентов для изучения?
    • А у SOC есть резервный канал и резервная площадка? А как докажут? “Зуб даю” тут не прокатит.
    • Как давно выбираемый SOC в бизнесе? Как у них с репутацией?
    • SOC готов вас свести с заказчиками, похожими на вас? А как долго они сами пользуются услугами SOC?
    • А что будет после завершения контракта с SOC?
    • Какие гарантии дает и какую ответственность несет SOC, если что-то пошло нет так (не увидел атаку, не смог среагировать, заблокировал не того)?
    • Вообще рекомендую посмотреть мой чеклист по выбору облачного провайдера с точки зрения безопасности. Любому аутсорсинговому партнеру можно задать вопросы оттуда и внешний SOC не исключение.

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


    А может податься в государственный CERT или ГосСОПКУ? Нууууу… Этот вопрос вообще не имеет отношения к вынесенному в заголовку. Строя свой или покупая услуги чужого SOC вы решаете свои задачи. Государственный центр мониторинга решает только свои. Вам он ничего не должен, не обязан, не гарантирует, и ни за что не отвечает. Не путайте свои интересы и интересы государства. Работа с государственными центрами имеет свои задачи и свою область применения - не смешивайте ее с темой SOC (если вы не госорган, конечно, но и тут есть нюансы).



    А вот над вопросом использования гибридного SOC стоит подумать более  серьезно. Но уже не сейчас :-)

    17.11.2015

    Васаби вам, а не статистику

    Пока в Москве вспоминают SOC-Forum, а Банк России подготовил проекты двух новых стандартов для  больших и маленьких некредитных финансовых организаций - СТО БР ИБНФО Б-1.0 и СТО БР ИБНФО М-1.0, я бы хотел вспомнить немного другой другой документ, выпущенный тем же регулятором. Речь идет об Указании 2831-У, который установил обязательную отправку ежемесячной отчетности по инцидентам информационной безопасности.

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

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

    Но... вот тут-то нас и поджидает засада. ДНПС забил болт на эту работу. За 3 с лишним года с момента вступления в силу 2831-У было выпущено всего 3 (!) отчета. Первый и второй касались данных по старой версии 203-й формы отчетности и датированы они второй и первой половиной 2012-го и 2013-го года соответственно. Потом был двухлетний перерыв и летом ДНПС разродился еще одним отчетом.

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

    В итоге доверие к обязательной ежемесячной отчетности об инцидентах подорвано и та задача, для которой эта отчетность вводилась, была провалена. Жаль... Это же, кстати, будет негативно влиять и на работу ЦБшного FinCERTа - он же тоже собирает данные по инцидентам. Но если одно подразделение ЦБ принимает эти данные как в черную дыру, то где гарантия, что и второе не будет делать тоже самое? Закономерный вопрос, который могут задать банки; особенно удаленные от Москвы.


    ЗЫ. Может быть хоть к Уральскому форуму 2016-го года такую статистику опубликуют?

    FinCERT: с чем его едят?

    Вчера я описал доклады по ГосСОПКА, прозвучавшие на SOC Forum. Сегодня пора обратиться к другому "государственному" центру мониторинга и реагирования на компьютерные инциденты. Речь, конечно же, пойдет о FinCERT. Я уже писал о том, что бы я хотел видеть от этой структуры. Теперь давайте посмотрим, что про это думает сам ЦБ, который представил на SOC Forum два доклада о работе FinCERT.

    В отличие от существующего SOC, который в ЦБ занимается защитой платежной системы Банка России, то есть выполняет внутренние задачи, FinCERT направлен вовне - на взаимодействие с объектами кредитно-финансовой сферы.

    И основная проблема, с которой сталкивается сейчас FinCERT - это доверие со стороны банков, которые пока не горят желанием делиться с центром мониторинга информацией об инцидентах. Об этом говорит сразу несколько фактов. И опрос, проведенный в рамках круглого стола на сентябрьской InfoSecurity Russia, и число участников, работающих с FinCERT - их 80 (в том же известном всем закрытом клубе почти в 7 раз больше банков), и рассказ замначальника ГУБиЗИ Артема Сычева о том, что они предупреждали некоторые банки об угрозах реализации против них DDoS-атак, но банки не прислушивались к рекомендациям ЦБ. Оно и понятно, одной рукой ЦБ приглашает делиться сведениями о проблемах с ИБ в банках, а другой отзывает потом у них лицензии. Понятно, что это разные "руки", но голова-то одна, и поэтому определенное недоверие к работе FinCERT есть и будет еще долго сопровождать эту структуру. На ее исправление придется потратить немало сил и времени.

    Но вернемся к тому, что делает FinCERT. Согласно презентации Дмитрия Фролова, руководителя FinCERT, входящего в состав ГУБиЗИ, созданный и скоро уже как полгода работающий центр мониторинга имеет дело с 4-мя типами инцидентов:

    • DDoS-атаки
    • Вредоносное ПО
    • Мошеннические SMS и звонки
    • НСД к конфиденциальной информации.
    Но список этот явно не формализованный, так как на презентации прозвучало, что можно даже об уязвимости в ДБО какого-либо банка написать и FinCERT должен посодействовать в устранении дыры. Кстати, как и НКЦКИ ФСБ, FinCERT с физлицами не работает - только с финансовыми организациями.



    Пока FinCERT собирает информацию. Делает он это из различных источников - СМИ, банки, мониторинг Интернет, ГосСОПКА (правда, непонятно как). Основной канал получения этих сведений - электронная почта. В отличие от GOV-CERT, который явно указывает PGP-ключ для обмена с ним информацией в защищенном режиме, FinCERT использует ничем не защищенный обмен. О возможности применения PGP на форуме говорилось, но о том, что это за ключ и как его получить (а также удостовериться в его подлинности) информации нет.


    Интернет-приемная ЦБ для этого малоприспособлена (проблемы те же, что и в GOV-CERT), а транспортные сервисы Банка России (как для 203-й формы отчетности) пока не заработали.

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



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


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


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

    Внутри FinCERT сидят аналитики, которые занимаются анализом получаемой информации об угрозах. Для этого используются как бесплатные (тот же VirusTotal), так и платные (упоминались фиды от Лаборатории Касперского) источники и инструменты. Про различные источники информации Threat Intelligence я уже рассказывал на SOC Forum и повторяться не буду, отправив читателя к своей презентации. Единственное, что могу добавить, что пока ни о какой стандартизации информационного обмена речи нет - данные об угрозах, а также индикаторы компрометации рассылаются в виде документов PDF или Word.
     

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

    Вот так выглядит на сегодня FinCERT. С прошедшего в феврале Уральского форума (а регистрация на новый уже открыта) видно движение вперед. Как в части налаживания работы самого центра и обеспечения его некоторой открытости (то, чего так не хватает ГосСОПКЕ), так и в части реальных результатов, о которых на SOC Forum говорил Руслан Стоянов из Лаборатории Касперского (есть реальные задержания киберпреступников).


    16.11.2015

    Что нового в SOC?

    По результатам моей заметки про SOC Forum мне многие написали, что ничего нового в теме SOCов нет и что примеры работающих SOCов известны уже не первый год. И что? Где в информационной безопасности вообще что-то новое? Сканеры безопасности? Так тот же SATAN был в начале 90-х разработан и что с тех сильно поменялось? IDS, которые сейчас все кому ни лень в России пишут (на базе open source)? Ну так первые сетевые IDS появились также в начале 90-х. Поведенческие анализаторы? Первые решения так и вовсе в 80-м году были представлены миру. NBAD? Тоже в 80-х. Да та же "инновационная" квантовая криптография была предложена еще в 70-х. Анализаторы кодов? Так первые решения в конце 70-х стали использоваться.

    Что нового в SOC? Ничего. Командные и штабные центры в войсках были с незапамятных времен. Но тогда еще компьютеров не было, чтобы собирать с них сигналы тревоги. В АНБ первый SOC появился в 1968 (тогда он еще назывался центром наблюдения (National SIGINT Watch Center), а в 1973 его переименовали в национальный SOC.

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

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

    Превратится ли ГосСОПКА в ГосКУРГАН?

    Прошедший SOC Forum запомнился еще двумя моментами - на нем впервые заговорили о работе FinCERT (предыдущие редкие упоминания не в счет) и в центре внимания была ГосСОПКА. Про FinCERT я напишу отдельно, а вот про ГосСОПКУ напишу сейчас. Хотя правильнее было бы сказать, что ГосСОПКА могла бы быть в центре, если бы о ней кто-нибудь сказал что-нибудь конкретное.

    2-го марта я уже писал про выступление представителя 8-го Центра на Уральском форуме по банковской ИБ с рассказом о СОПКЕ. Однако никаких деталей о работе системы представлено не было, кроме известных вещей из 31-го Указа Президента, которому в январе стукнет 3 года. И это несмотря на то, что сама система к моменту рассказа о ней уже существовала и работала. На SOC Forum была надежда, что о системе расскажут гораздо больше. Все-таки к этому моменту уже и Концепция государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации уже было утверждена.

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


    Лично мне хотелось бы услышать что-нибудь о том, что и как будет делать главный центр ГосСОПКИ и НКЦКИ. По последнему центру (он же GOV-CERT) сказано ничего не было и, несмотря на присутствие в зале представителей госорганов, принципы, время, инструменты работы центра реагирования на инциденты так и остались тайной за семью печатями. Однако по тому, как работает сайт gov-cert.ru уже есть определенные вопросы и замечания.

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


    В какой часовой зоне находится центр реагирования? С 9 утра до 6 вечера связываться можно по какому времени? Московскому? А может быть Хабаровскому?


    А что делать, если инцидент произошел ночью? Если посмотреть на статистику JSOC, генерального спонсора SOC Forum, то мы увидим что внешние инциденты происходят преимущественно ночью. И куда с ними бежать?


    Есть у меня и еще один простой вопрос. Почему передача информации из формы уведомления об инциденте передается в открытом и никак незащищенном виде? Например, для общения по почте GOV-CERT предлагает использовать PGP (неплохо бы его еще и в виде файла разместить), а для формы? Даже HTTPS не поднимается. При этом, как следует из описания ведомственных центров ГосСОПКА, которые должны передавать информацию об инцидентах в своих ведомствах, они должны общаться с Главным центром с помощью сертифицированной криптографии. Неувязочка :-(


    По данной форме возникает и другой вопрос. А кто-нибудь думал об удобстве использования результатов, помещаемых в данную форму? Я понимаю, что она "срисована" с аналогичной формы Group-IB, но где классификация/систематизация информации? Посмотрите на то, как сделана форма уведомления об уязвимостях на оригинальном сайте CERT/CC. Тут и возможность загрузки файлов, и больше полей для описания проблемы, и даже возможность отслеживать взаимодействие с CERT/CC по номеру тикета (tracking ID). А gov-cert спрашивает про наличие лог-файлов, но не предлагает формы/кнопки для их подкачки. Без систематизации хотя бы первичной информации всю эту информацию из формы придется считывать вручную, что замедляет работу по инцидентам.

    Форма об инциденте на сайте Group-IB
    Кстати, GOV-CERT работает всего с тремя типами инцидентов - DDoS, ботсети и вредоносное ПО, а также несанкционированный доступ к информационным системам госорганов. Аналогичный американский US-CERT добавляет к этой тройке, еще 4 типа инцидентов - киберучения, сканирование и попытки доступа, нарушение госслужащими правил безопасности и неподтвержденный инцидент.

    Про автоматизацию отправки информации об инцидентах тоже пока говорить не приходится. И хотя аналогичная проблема присутствует почти во всех мировых CERTах, стоило бы подумать об API или использовании того или иного стандарта описания инцидентов. Хотя бы потому, что в ряде ведомств и госкорпораций уже создан свой центр ГосСОПКИ, который может в автоматизированном режиме передавать информацию в НКЦКИ. Например, такой центр есть в РЖД. Точнее их там несколько - построенных на базе ArcSight и на базе импортозамещенных технологий (об обоих был рассказ на SOC Forum).


    Возможно со временем НКЦКИ и превратится в нечто похожее на раздел сайта ENISA по поддержке региональных и корпоративных CERTов (или на европейский CERT), но пока до этого ой как далеко. Да и долго. Бюрократия убивает идею центра реагирования на корню. Кстати, у европейского CERTа есть и свое мобильное приложение. Будет ли когда-нибудь такое у 8-го Центра?..


    С ведомственными центрами ГосСОПКИ ситуация была чуть более понятная. Представитель 8-го Центра ФСБ озвучил основные задачи ведомственных центров:
    • выявление признаков проведения компьютерных атак формирование и поддержание в актуальном состоянии детализированной информации об информационных ресурсах, находящихся в зоне ответственности ведомственного центра
    • сбор и анализ информации о компьютерных атаках и вызванных ими компьютерных инцидентах
    • проведение мероприятий по оперативному реагированию на компьютерные атаки и вызванные ими компьютерные инциденты, а также по ликвидации последствий данных компьютерных инцидентов в информационных ресурсах
    • принятие управляющих решений по обеспечению информационной безопасности информационных ресурсов
    • выявление, сбор и анализ сведений об уязвимостях, а также проведение мероприятий по оценке защищённости от компьютерных атак и вирусных заражений информационных ресурсов
    • информирование заинтересованных лиц и субъектов ГосСОПКА по вопросам обнаружения, предупреждения и ликвидации последствий компьютерных атак 
    • обеспечение защиты данных, передаваемых между ведомственным центром и Главным центром по каналам, защищённым с использованием сертифицированных ФСБ России средств защиты информации
    • предоставление дополнительной информации о компьютерных инцидентах в информационно-телекоммуникационных сетях, находящихся в зоне ответственности ведомственного центра, по запросам Главного центра ГосСОПКА.
    О том, как строить такие ведомственные центры в 8-м Центре не знают. Иначе как объяснить тот факт, что они разослали по госорганам не ТЗ с описанием центра, его интерфейсов, описания полей информации и других моментов, облегчающих интеграцию, а всего лишь запрос с требованием предоставить планы создания таких центров. То есть ТЗ должны будут писать сами ведомства, а затем согласовывать их с 8-м Центром ФСБ.

    У иностранных вендоров SIEM появляется призрачный шанс залезть на эту поляну. Но шанс призрачный, потому что 8-ка известна своей любовью к решениям сертифицированным, а значит все SIEMы должны обладать соответствующей бумажкой. Но выданной кем? ФСТЭК или ФСБ? И на соответствие каким требованиям? ФСТЭК в лице Лютикова на SOC Forum заявила, что пока они требования по SOCам/SIEMам не планируют разрабатывать. На что же тогда ориентироваться  ArcSight, Splunk и другим 72 SIEMам, известным в мире (вот список). Ну а судя по тому, что второй доклад по ГосСОПКА с ответами на вопросы о ней вместо представителя 8-го Центра делала компания  Positive Technologies, думаю, что явный фаворит для технологической платформы ГосСОПКИ уже определен и им будет MaxPatrol SIEM.

    Что ждет Главный центр ГосСОПКИ от ведомственных центров? Три типа данных:

    • Информация о выявленных компьютерных атаках
    • Информация о выявленных компьютерных инцидентах
    • Результаты проведения оценки защищенности.
    Тем ведомствам, которые уже у себя внедрили SIEMы, сканеры защищенности и SOCи будет попроще разобраться с этой информацией. Вот как, например, выглядит форма об инциденте в центре мониторинга ИБ РЖД.

    Главный же центр ГосСОПКИ будет отдавать ведомственным и, возможно, корпоративным центрам другую информацию:
    • Информация о признаках компьютерных инцидентов
    • Индикаторы вредоносной деятельности
    • Сведения об угрозах безопасности информации
    • Методические рекомендации по противодействию выявленным угрозам.
    Вот с последним пунктом тоже есть вопросы. Как я уже писал, 8-му Центру предстоит разработать большое число методических документов. Но когда они будут разработаны совсем непонятно. Судя по оперативности выпуска этим регуляторов документов ждать придется долго :-(

    13.11.2015

    Positive отказался от вывода своего SOCа на рынок!

    Знаете ли вы сколько продуктов/решений по ИБ вы используете в своей сети? 5, 10, 20?.. А сколько их существует в России? А в мире? Начнем с последнего вопроса. На последней RSA Conference было представлено около 400 мировых игроков в области информационной безопасности. За последние пять лет свыше 1200 ИБ-стартапов получили инвестиции на свое развитие.

    Из презентации Cisco по проблемам ИБ
    Если верить статистике InfoSecurity Russia 2015, то на стендах было выставлено 344 продукта по ИБ, а игроков было представлено больше 75. А теперь подумайте над первым вопросом. Сколько разных у вас МСЭ, IDS, NGFW, антивирусов, SIEM, DLP, средств контентной фильтрации, NAC, IdM, шифровалок, СЗИ от НСД, сканеров безопасности, PKI, средств ЭП? Уже с десяток только типов средств защиты. А если они местами дублируют друг друга. А местами они от разных производителей. А еще разные системы стоят в разных местах сети (на периметре, на серверах, на рабочих станциях).

    По данным Cisco среднее предприятие в США использует средства 54 разных производителей ИБ. По версии Symantec, среднее предприятие использует 75 (!) разных средств защиты. Идеально было бы завести это все на SIEM/SOC (не буду делать пока разницы между ними, тем более, что и так мало кто это деление делает). И вот тут мы упираемся в ограничения современных SIEM-решений. Они обычно поддерживают только самые распространенные решения по ИБ или используют общие для всех механизмы сбора событий (тот же Syslog), ни фига не понимая сути получаемых сигналов. Учитывая, что в России пока наибольшей популярностью пользуются импортопоканезапрещенные SIEM, то многих привычных в России средств защиты они не понимают.

    Можно, конечно, разработать свои коннекторы. Так, например, было сделано в Splunk для решений "Кода безопасности" (SSEP, Континент, vGate, Secret Net) и используется в Многофункциональном миграционном центре г.Москвы. Но это частный случай. Продуктов все равно на рынке больше больше.

    Splunk Smart Monitor с подключенными решениями "Коде безопасности"
    Что делать? Можно ограничиться только некоторыми, самыми распространенными решениями. Так поступили в  SOCе "Перспективного мониторинга" (дочка Инфотекс). Тоже вариант и достаточно распространенный. Подключение всех нетиповых продуктов решается в каждом случае отдельно.

    Центр мониторинга "Перспективного мониторинга"
    Есть третий путь. Его озвучил на SOC Forum Алексей Качалин из Positive Technologies. По его словам, в компании проанализировали ситуацию на рынке и поняли, что не смогут подключить к уже созданному SOCу все имеющиеся у заказчиков средства защиты. Половинчатое решение Positive не устроило и они приняли решение... не выводить свой SOC на рынок! Фанфары!!!


    Это было фееричное заявление, сорвавшее если не бурю, то маленький тайфунчик аплодисментов. На самом деле, PT решили пойти немного иным путем. Они трансформировали свое видение SOC в ESC (Expert Security Center), который и предлагает свои услуги другим SOCам или MSSP, работающим на российском рынке. По сути речь идет о субподряде, в рамках которого эксперты Positive Technologies берут на себя часть задач, решаемых SOC.

    ЗЫ. Вы думали, что утренняя заметка про SOC Forum была последней в череде публикаций на тему SOCов? Нет! Все только начинается. Планы у меня есть еще на несколько заметок.

    ArcSight Forum или SIEM Forum или SOC Forum? Что это было?

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

    SOC!... Как много в этом слове, для сердца безопасника слилось и чем-то там отозвалось. Вот это что-то и вызвало колоссальную бурю эмоций у участников, каждый из которых пытался придать этому термину свой смысл и свое звучание. SOC - это центр мониторинга. SOC - это центр реагирования. SOC - это ЦОД. SOC - это SIEM. SOC - это служба ИБ. Лучше всего к пониманию термина Security Operations Center подобрались коллеги из Информзащиты, которые высказали мысль, что "за ваши деньги мы назовем SOCом все что угодно" :-) Смешно, но доля правды в этом есть. В начале пленарки, когда Олег Седов, модерирующий мероприятие, попросил нас высказаться об этом термине, я сразу сказал, что не надо сейчас вдаваться в терминологию - ничем хорошим это не закончится. Существует известная пословица: "Хочешь завалить мероприятие по ИБ, начни дискуссию о терминологии".

    С одной стороны это плохо, так как дальше мероприятие проходило по принципу "кто в лес, кто по дрова". Один докладчик рассказывал про SIEM, выдавая его за SOC. Другой приводил картинки SANS, делал вывод о том, что SOC и служба ИБ - это суть одно и тоже, и сразу же переходил к рассказу о пентестах, которые этими службами ИБ не замечаются (причем тут SOC?!). По сути, многие участники решили свои компетенции и продукты подтянуть под термин SOC, либо не понимая что это, либо понимая, но желая получить доступ к большой аудитории. Вспоминается известный анекдот: "Приходит студент в ветеринарную академию на экзамен по биологии, но ничего не знает, кроме строения блохи. Достался ему билет про корову. Он выходит и начинает: - Корова - это такое животное, на четырех ногах, покрыто шерстью. В шерсти водятся блохи... - И дальше рассказывает все про блох. Преподаватель его останавливает и говорит: - Хорошо, хорошо. Расскажите нам лучше про собаку. Студент опять начинает: - Собака - животное на четырех ногах, покрыто шерстью, в шерсти водятся блохи. И дальше рассказывает про блох. Экзаменатору это надоело, и он говорит: - Ладно, расскажите нам про рыбу. - Рыба - это животное, которое живет в воде. Шерсти у рыбы нет, но если бы была, в ней водились бы блохи..."

    А поскольку подтягивать было особо не к чему (даже в мире с этим термином есть путаница), то и на выходе получилась полная чехарда с зернами истины. Если уж с термином "персональные данные", которые введен законодательством уже скоро как 10 лет, до сих пор много неразберихи. Что же говорить о термине, который ни в одном документе не упоминается.  Кстати, о персональных данных. Не зря в афоризмах с SOC Forum есть фраза, что какую бы тему в ИБ не взять, все придет к персональным данным. Так было и на пленарке - первую ее половину говорили либо про персданные, либо про регулирование, что достаточно странно выглядело бы на каком-нибудь форуме SANS по SOCам (вот презентации с последнего SANS SOC Summit), но привычно в России. Кстати, днем ранее проходила конференция РКН по персональным данным (часть 1 и 2 отзыва Михаила Емельянникова) и людей там было на порядок (именно на порядок) меньше, чем на SOC Forum.

    Что же касается регуляторов, то интересная петрушка приключилась. Регуляторы-то особо и не видят смысла в этой всей сочной истории. Виталий Лютиков (ФСТЭК) сразу сказал, что все это маркетинг и шумиха, нагнетаемая интеграторами и продавцами. Артем Сычев (ЦБ) здраво отметил, что в принятом в 2012-м году 382-П (да и в СТО во многом тоже) тема управления ИБ, ее мониторинга и реагирования на инциденты раскрыта полностью. Да, ее там никто не называет SOCом, но все необходимые элементы, которые преподносятся как часть SOC, в 382-П есть. Да и в 17/21/31-м приказах тоже все это есть. И реагирование, и управление событиями ИБ. Более того, и нормативка ЦБ, и ФСТЭК, гораздо лучше подходит под понятие SOC, чем представляемые на рынке SOC. Потому что регуляторы в своих требованиях описали все операции безопасности (security operations), а поставщики SOCов концентрируются вокруг самых типовых  - мониторинга и реагирования.

    Как человек, который участвовал в подготовке вопросов к пленарке, я включил в них один, который меня интересовал. Каковы гарантии аутсорсингового SOC в случае “успешной” атаки на информационные системы клиента и какую ответственность несет SOC в этом случае? Предсказуемо поставщики услуг SIEM/SOC стали уходить от прямого ответа, ссылаясь на то, что за всё всё равно отвечает заказчик и что SOC не может ничего гарантировать. В итоге, когда одного из участников дискуссии приперли к стенке, он сказал, что страхование от ответственности надо включать в стоимость контракта и все :-)

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

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

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

    Это закономерно вызвало удивление и неприятие со стороны регулятора. Ни ФСТЭК, ни ЦБ особо не горели желанием влезать еще и в тему регулирования SOCов. Артем Сычев сказал, что эта тема и так частично закрыта в СТО БР ИББС и 382-П, а Виталий Лютиков и вовсе высказал претензию (и не первый раз уже) к индустрии ИБ, заявив, что рынок должен регулировать себя сам, а не ждать, когда придет регулятор и за всех все решит. Это возможно только для госорганов, где владельцем информации является государство и именно оно, через ФСТЭК, устанавливает те или иные требования. Остальные пусть выкручиваются сами. Если уж сообществу SOCов (а в России есть закрытое общественное объединение "SOC России", в котором кучкуются любители SOCов и которые собираются на закрытые для посторонних посиделки) так нетерпится получить требования, то они могут это сделать через разработку ГОСТа и регистрацию его в Ростехрегулировании (через ФСТЭКовский ТК362 или ЦБшный ТК122). Желающих не нашлось, но возможно эта тема и найдет своих благодарных последователей, которые подготовят такой стандарт. Хорошо высказался Александр Скакунов: "На рынке выиграет тот, кто найдет мотивацию "пряник". На этом этапе кнуты в виде сертификации и регулирования забьют здоровые гвозди в крышку коробочки, где будет покоиться SOC".

    Кстати, раз уж я вспомнил Александра, то нельзя не вспомнить и организованное его компанией мероприятие VolgaBlob Trends 2015 (а до это и 2014), которое прошло неделей раньше SOC Forum, и на котором также поднимались вопросы мониторинга ИБ. А еще двумя неделями ранее в Москве прошел уже второй Splunk Moscow Summit, посвященный... точно, SIEM (или как говорят некоторые неSIEM) Splunk. На нем, как это не странно, тоже говорили про мониторинг ИБ на базе решений Splunk. Но это же мероприятие одного продукта, а SOC Forum был независимым, скажете вы. Ага, счас :-)

    Я не зря в названии заметки упомянул про ArcSight. Именно он постоянно упоминался участниками мероприятия. Он используется в JSOC, он используется в Информзащите, он используется в АМТ, его использует РЖД, его использует Газпромбанк... Да много он где используется. Если бы не искрометное выступление Олеси Шелестовой из RuSIEM, то можно было бы поставить знак равенства между SOC Forum и ArcSight Forum :-)

    Но давайте закончим с пленаркой и вернемся к SOCу. Определились ли участники хотя бы к  окончанию мероприятия с тем, что такое SOC? Увы... Как справедливо заметил Дмитрий Мананников: "Про SOC так и не поговорили. Все про выстроенные SIEMы". Артем Агеев был более циничен - "SOC - это новая "безопасность АСУ ТП" :-) Соглашусь с обоими, но при этом все равно еще раз отмечу, что мероприятие мне понравилось. Я это предсказывал еще до начала и не ошибся. Да-да, я пророк; через меня течет Сила :-)


    Тема (для России) новая. Она ближе к традиционной ИБ, чем безопасность АСУ ТП. Она назрела. Я уже как-то приводил в пример число 50. Именно столько ИБ-решений на среднестатистическом предприятии (по данным Symantec их вообще 70+). А людей не хватает; и сильно не хватает. Поэтому и тема SIEM (как мониторинг большого количества разрозненных средств защиты), и тема SOC, и особенно аутсорсинг и того, и другого, будет востребована в ближайшее время. А уж как это все называть, дело десятое. Со временем этот термин сформируется сам собой; как только появится активная практика, а не единичные кейсы.


    ЗЫ. Материалы с форума уже выложены.

    12.11.2015

    Microsoft покупает Secure Islands

    9 ноября компания Microsoft объявила о приобретении израильского малоизвестного в России (да и не только) разработчика решений по предотвращению утечек информации - Secure Islands. Сам стартап называет себя инноватором в области продвинутой защиты информации. Видимо ребята не хотят ассоциироваться с термином DLP :-) Хотя по описанию оно так и есть. Технологии Secure Islands войдут в состав Azure Rights Management Service. Размер сделки не сообщается.

    ЗЫ. Вообще Microsoft что-то потянуло на израильские стартары по ИБ. Сначала Aorato, потом Adallom. Теперь вот Secure Islands.

    Моя презентация с SOC Forum по Threat Intelligence для SOC

    Обзор SOC Forum еще ждет своего часа и уж поверьте, я выскажу всю правду про это замечательное мероприятие :-) А пока выложу свою презентацию, которую я посвятил теме знаний об угрозах (threat intelligence), источникам их получения, платформам для их обработки и обмена, API для автоматизации работы с ними, а также стандартам, позволяющим более эффективно выстроить работу с Threat Intelligence как самостоятельно, так и в составе Security Operations Center (SOC).



    SOC Forum в социальных сетях

    Пытливый читатель, прочтя 45 афоризмов с SOC Forum, успел задаться вопросом, а в каком зале и в какой презентации говорили про беременность Юлии Снигирь и как вообще эта тема связана с SOC? Все очень просто. Именно эта тема, сопровождаемая тегом #SOCForum2015 стала популярной в Twitter :-) И не только она


    Достаточно интересная ситуация. Связана она с тем, что тег #SOCForum2015 достаточно быстро стал популярен. И несмотря на то, что официальным тегом был #socforum, именно новый, с приставкой 2015, завоевал популярность. А все потому, что общественное объединение "SOC России" запустил конкурс, одним из условий которого было использование именно тега #SOCForum2015. Призы интересные... Отсюда и интерес у участников и активное использование социальных сетей. Популярность тега привела к тому, что на него обратили внимание спамеры:


    По моим оценкам число твитов, посвященных форуму, и посвященных всякой ерунде, были примерно равны :-)



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


    Но это не все, чем отличились социальные сети вчера. Пока шел SOC Forum, в Facebook Илья Сачков высказал свое мнение о мероприятии и о том, кто там участвует. Мнение, мягко скажем, нелицеприятное и мне непонятное. Обиду в нем замечаю я :-)
    Следуя этой логике, можно задаться множеством аналогичных вопросов:

    • Как можно заниматься разработкой ПО, не имея опыта работы в Microsoft?
    • Как можно заниматься средствами борьбы с ботнетами, не имея опыта работы в Cisco или OpenDNS или Sourcefire?
    • Как можно руководить компанией, не имея опыта руководства американской корпорацией?
    • Как можно ходить в Сколково за деньгами на свой стартап, не имея опыта хождения за деньгами инвесторов в Кремниевой долине?
    • Как можно заниматься защитой Интернет, не имея опыта работы в Google?
    • Как можно ездить на Ладе, не имея опыта езды на BMW?
    В любом случае, я так и не понял причины такого отношения к мероприятию, которое по общим оценкам стало одним из лучших в последнее время. Обида, что не пригласили? Или пригласили, но попросили денег? Фиг знает.

    В любом случае, могу отметить, что ИБ-мероприятия стали освещаться в социальных сетях гораздо лучше, что отрадно :-)

    45 афоризмов SOC Forum

    По результатам завершившегося вчера SOC Forum сделал интересное наблюдение. Интерес к теме и к мероприятию можно оценивать по числу звучавших афоризмов. На SOC Forum их число зашкалило. Взял на себя смелость выписать основные, запомнившиеся мне. Есть просто шедевры. Уже только по ним можно составить впечатление от прошедшего мероприятия :-)

    1. Что такое СОПКА? Нет, не знаю (с)

    2. За ваши деньги мы что угодно назовем SOCом (с)

    3. Лукацкий не последний, а крайний (с)

    4. SOC - это как подростковый секс (с)

    5. Два регулятора и Сычев (с)

    6. Требования регулятора - зло, но их очень надо больше чтобы было лучше (с)

    7. Обмен событиями между SOC'ами - это SEX (Security Event eXchange) (c)

    8. До чего дожили, Лукацкого перебивают из зала (c)

    9. Задача SOC - противодействовать деградации ИБ в "мирное время" (с)

    10. Ваш SOC забродил (с)

    11. Страхование от ответственности входит в стоимость контракта (с)

    12. И чем не SOC snort? (с)

    13. - SOC начинается где?
    - Где начинается что?
    - Что как? (с)

    14. SOC - это в первую очередь глаза (с)

    15. Пресса она такая: и деньги возьмёт и правду напишет (с)

    16. И это тоже SOC. А почему бы и нет? (с)

    17. Что будет если атака выбивает ваши сигнатуры? (с)

    18. ГосЖОПКА (с)

    19. Данные от источников Threat Intelligence как сплетни (с)

    20. SIEM - это агрегатор логов (с)

    21. SOC и служба ИБ - это одно и тоже (с)

    22. FinCERT не будет соковыжималкой (с)

    23. SOC - это почти тоже самое, что ЦОД (с)

    24. SOC - это подзорная труба (с)

    25. SOC - это термометр ИБ (с)

    26. SIEM не состояние, не очень сюда градусник подходит (с)

    27. Да хрен с ней, с едой, главное контент (с)

    28. И каждая кухарка будет реверсить, реверсировать и реверсироваться (с)

    29. Наше счастье что Артемий Лебедев дизайны SOC-ов не делает (с)

    30. Любая тема по ИБ в России всегда сводится к персданным (с)

    31. Любая тема по ИБ в РФ сводится к регулированию. Да и вообще любая тема в РФ. Да и вообще любая (с)

    32. Чудесный срач на пленарке (с)

    33. Срочно покупай SOC. Потом все объясню... (с)

    34. Самый сок из поИБ (с)

    35. В каком зале про беременность Юлии Снигирь? (с)

    36. Про SOC так и не поговорили... (с)

    37. SOC выполняет совершенно другие задачи, чем Центр мониторинга (с)

    38. Хочу поддержать регуляторов: плохое регулирование лучше, чем никакое (с)

    39. Взяли и опошлили всю красоту аутсорсинга (с)

    40. Красота и пошлость - разные вещи. У нас есть вкус, чтобы понять, где нам пытаются выдать второе за первое (с)

    41. Развивать SOC - как растить слона. Слоник без ножек - чистый пассив (с)

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

    43. Стоимость нашей сертификации по сравнению с ценой на ваши SOCи покажется детским лепетом! (с)

    44. В России два развлечения : революция и сертификация (с)

    45. so-SOC (c)


    11.11.2015

    Bluecoat покупает Elastica

    9-го ноября американская Bluecoat, проданная инвестиционным фондом Thoma Bravo и принадлежащая с марта этого года фонду Bain Capital, объявила о приобретении небольшого американского стартапа в области облачной безопасности - Elastica. Сумма сделки составила 280 миллионов долларов.

    Книги про проектирование, построение и эксплуатацию SOCов

    А мы продолжаем нашу эпопею, посвященную SOCам. Вообще, сегодня, в день проведения SOC-Forum, я не хотел ничего писать про них, отдав место под другую публикацию. Но совершенно случайно, хотя очевидно, что Google подсовывает в выдаче явно не случайную выборку ссылок, я наткнулся на опубликованную неделю назад книжку "Security Operations Center: Building, Operating, and Maintaining your SOC".


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

    Первая часть посвящена обзору проблем с ИБ, описанию 4-х поколений SOCов (чем сложнее атаки, тем более взрослое поколение SOCов позволит эти угрозы обнаруживать и нивелировать), моделям зрелости, оценке эффективности SOC, сложностям реализации и другим вводным и обзорным темам. В ней же приводится и обзор технологий, используемых современными SOCами, - сбор данных, управление уязвимостями, Threat Intelligence (я про это сегодня на SOC-Forum буду рассказывать), соответствие требованиям, управление кейсами и взаимодействие.

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

    Разумеется не обошлось и без погружения в терминологию, о которой я уже тут писал, и о которой вчера написал Эльман Бейбутов на Anti-Malware. Не буду сейчас описывать, что же авторы книги имели ввиду, говоря про SOC, SIEM, SIM, SEM, CSIRT и другие термины, а то опять погрязнем в терминах, забыв о главном.


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

    Раз уж нашлась одна книга, стал искать и другие. Нашел. Но только еще одну. Называется "Designing and Building a Security Operations Center".


    Эта книга совершенно иная - в ней 11 частей, каждая из которых посвящена своей теме:

    • Эффективные операции 
    • Идентификация целевой аудитории для SOC
    • Инфраструктура SOC
    • Оргструктура
    • Персонал и взаимодействие с другими людьми
    • Ежедневные операции
    • Тренинги
    • Метрики
    • Threat Intelligence
    • Аутсорсинг.
    В отличие от предыдущей книжки, систематизированной по этапам жизненного цикла центра управления ИБ, данный манускрипт больше похож на свод правил "делай так и не делай вот так". Такое впечатление, что автор свои записи "по теме", сделанные на стикерах, просто собрал вместе, как-то разбил по главам, и опубликовал в виде книги. Не скажу, что книга от этого стала хуже - даже наоборот; она интересна именно своей практичностью и примерами.

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


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

    С содержанием обеих книг можно ознакомиться с помощью сервиса Google.Books: