ФинЦЕРТ и ГосСОПКА: как им жить вместе #socforum

На прошлой неделе Банк России выложил на официальный портал размещения проектов нормативных актов проект указания "О внесении изменений в Указание Банка России от 9 июня 2012 года № 2831-У "Об отчетности по обеспечению защиты информации при осуществлении переводов денежных средств операторов платежных систем, операторов услуг платежной инфраструктуры, операторов по переводу денежных средств". Я про него уже писал в августе (с тех пор оно не изменилось), но этот проект заставил меня коснуться темы связи между ФинЦЕРТом Банка России и ГосСОПКОЙ, о которой я так ничего и не услышал в рамках прошедшего SOC Forum. Будем считать эту заметку первой в серии по результатам московского SOC Forum 2017.

Стенд ФинЦЕРТ на SOC Forum (фото АвангардПро)

Итак, что же я хотел услышать на SOC Forum про взаимоотношения ГосСОПКИ и ФинЦЕРТа? Ответ на очень простой вопрос - как финансовые организации, которые окажутся владельцами значимых объектов КИИ, должны будут сообщать об инцидентах в ГосСОПКУ при условии, что сейчас они и так (правда, по требованиям ЦБ, а не ФЗ-187) отправляют данные об инцидентах в ФинЦЕРТ? В части 552-П такая отправка осуществляется в течение 3-х часов с момента наступления/обнаружения инцидента. По 2831-У 203-я форма отчетности об инцидентах направляется раз в месяц. По проекту изменений в 2831-У, упомянутому выше, это будет делаться раз в квартал или раз в полгода и отчетность не будет содержать данных об инцидентах. Такое изменение связано с тем, что в проекте новой редакции 382-П написано, что все данные об инцидентах направляются в ФинЦЕРТ в порядке, установленном Банком России и размещенном на официальном сайте ЦБ. Такого порядка еще нет, но я не думаю, что там будет указано значение, отличное от 552-П, то есть 3 часа на уведомление об инцидентах.

А теперь вновь повторю вопрос. Финансовая организация, владеющая значимым объектом КИИ, должна направлять данные об инцидентах только в ФинЦЕРТ (а он уже сам все отправит дальше в ГосСОПКУ) или помимо ФинЦЕРТа надо дублировать информацию и для ГосСОПКИ? Вопрос непраздный. Первый вариант предпочтительнее для всех, так как он не меняет сложившейся за последнее время ситуации.

Артем Калашников, руководитель ФинЦЕРТ

Но чтобы реализовать этот сценарий нужно, чтобы ФинЦЕРТ числился корпоративным или ведомственным центром ГосСОПКИ. Однако, согласно методическим рекомендациям ФСБ по созданию ведомственных и корпоративных центров ГосСОПКИ к таковым относятся только:

• госкорпорации
• операторы связи
• лицензиаты в области защиты информации
• органы госвласти.

Так вот особый статус Банка России, который не относится ни к одной из этих 4-х сущностей, не позволяет стать ему ни корпоративным, ни ведомственным центром. И отсюда вытекает сразу два важных вопроса вопрос:

• Придется ли финансовым организациям направлять данные об инцидентах в ГосСОПКУ напрямую? Судя по ст.9.2 ФЗ-187 да, придется отправлять данные об инцидентах в обе стороны - ФинЦЕРТ и ГосСОПКУ. Хотелось бы, конечно, уменьшить число точек входа.
• В течение какого интервала времени надо будет отправлять сведения об инцидентах? В ст.9.2 ФЗ-187 говорится "незамедлительно". Что это означает? Не хотелось бы, чтобы у ФСБ и ЦБ были разные порядки уведомления, что повлечет за собой удвоение работы по выполнению требований и ФЗ-187 и 382-П/552-П.
• Если финансовые организации вынуждены будут отправлять данные об инцидентах в ГосСОПКУ, то как это должно происходить? Кто будет тем корпоративным центром, который будет принимать данные от финансовой отрасли и отправлять их в головной центр ГосСОПКИ? А самое главное, будет ли это бесплатно?

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

Зато выступление Андрея Думанского из ФинЦЕРТ было неплохим - подробно были освещены направления деятельности ФинЦЕРТ, достигнутые результаты, сложности в работе. Из нового (по сравнению с ранними выступлениями на InfoSecurity Russia и закрытом клубе SOC Club) я бы отметил следующие моменты:

• вступление ФинЦЕРТ в FIRST и EAST EGAF
• проведение криминалистических экспертиз (компьютерных исследований)
• автоматизацию процесса отправки индикаторов компрометации (до конца года хотят запустить).

ЗЫ. На смену упомянутым выше методическим рекомендациям ФСБ готовит требования к корпоративным и ведомственным центрам. Может быть там учесть статус ФинЦЕРТ? Правда, статью 9.2 ФЗ-187 это все равно не отменит.

Подробнее…

Демотиваторы и смешные картинки с #socforum

Решил по традиции выложить все демотиваторы и смешные картинки, которые я делал для последнего SOC Forum:

Подробнее…

Бывает ли кибербезопасность с десяти до шести?

Незапланированная заметка, навеянная тремя событиями. Началось все позавчера, когда Дима Мананников опубликовал в Фейсбуке заметку про безопасность смарт-контрактов, ICO и всего такого и, не увидя бурной дискуссии от коллег, высказал удивление сему факту. Мол, задача безопасника - отслеживать все новые бизнес-технологии и искать способы их безопасного внедрения/использования в бизнесе. Я ему возразил и в итоге завязалась дискуссия, в которой я высказал следующую мысль: "Безопасник в массе свой рядовой сотрудник, выполняющий трудовые обязанности с 10 до 6. Он ничем не отличается об уборщицы или бухгалтера. Им всем комфортно в своем болотце и менять что-то они будут только в экстренных ситуациях. Плюс образование, которое учит compliance и борьбе мо старыми угрозами. Отсюда все. Исключения бывают, но только подтверждают общее правило".

Подтверждение моему высказыванию я получил относительно недавно на одном крупном предприятии, которое любит выпячивать свою экспертизу в области ИБ. В рамках очередного моего приезда к ним и рассказа о том, как у нас в компании выстроен процесс реагирования на инциденты, я рассказал о сервисе Cisco Umbrella Investigate, позволяющего оперативно и без установки какого-либо железа и софта у заказчика (и даже без какой-либо их перенастройки и перенаправления трафика) проводить анализ инцидентов, связанных с Интернет-активностью. Решение заинтересовало заказчика, тем более, что он запустил свой SOC, в рамках которой работала группа по расследованию инцидентов и Threat Intelligence. От нас оперативно потребовали триальный доступ для тестирования, что мы и сделали. Прошел месяц. На очередной встрече у этого заказчика представитель группы реагирования на инциденты в присутствии большого руководства отчитался о завершении тестировании Investigate и нахождении ряда интересных кейсов. Руководство заинтересовалось и попросило показать систему в действии... И вот тут случился казус. Я с ноутбука зашел в панель аналитика и предложил представителю incident response team показать, что он обнаружил. Но в глазах его я увидел, что он в первый раз видит панель аналитика Investigate. Заподозрив неладное, я хотел спустить дело на тормозах, но большое руководство заказчика потребовало "красивых картинок и схем", за которыми последовал ужасный вывод - выяснилось, что IRT заказчика даже не активировало предоставленный им временный доступ и он, разумеется, уже "протух". Оставлю за рамками произошедший после этого разбор полетов, но меня неприятно поразило отношение некоторых безопасников к своим обязанностям. Чем-то это напомнило Советский Союз с его победными реляциями, отчетами о деятельности для галочки и очковтирательством :-(

Финальным аккордом стали комментарии Михаила Никишина к моей заметке про семинар Gartner, который высказал (да уже и не первый раз) мысль, что в нашей отрасли ИБ вообще нет безопасников (вспоминаем сентябрьский чеклист "настоящий ли ты безопасник?"), а только одни айтишники с их специфическим мышлением и способом решения задач. Не совсем я согласен с Михаилом, но доля истины в его словах есть. Кибербезопасность превратилась в обычную деятельность, как и сотни других профессий. И многие специалисты действительно работают с 10 утра и до 6 вечера, напрочь забывая про ИБ за пределами времени, установленного Трудовым Кодексом.

По сути, большинство "безопасников" действительно погрязли в своей зоне комфорта и выйти из нее зачастую не могут или не хотят. Лет 10 назад я приехал к одному знакомому, руководившему сектором ИБ в одной организации. Мы поговорили о том, о сем, и я предложил ему рассмотреть несколько технологий и решений, которые могли бы помочь ему в озвученных им проблемах. И что же вы думаете? Он отказался, сославшись на то, что его все и так устраивает, а новые решения - это новая головная боль, а ему хотелось бы сидеть на попе ровно и не напрягаться по поводу чего-то нового. Он до сих пор сидит на своей должности, не выходя из зоны комфорта, не занимаясь развитием. Хотя я и встречаю его регулярно на различных ИБ-тусовках, где он задает якобы каверзные вопросы, но в своей практике затем полученные знания никак не использует. Грустно это...

Дмитрий удивляется, почему безопасники не занимаются бизнес-стороной своей деятельности. Я же удивляюсь, почему они не занимаются даже просто новыми технологиями ИБ. NTA, EDR,  UEBA, IAG/IGA, PAM, CASB, SDS, SDP, SOAR, DDP, SIG, RASP, SAT, NFT и др. Нет денег? Не смешите. Бюджеты у многих заказчиков измеряются сотнями миллионов, а то и миллиардами рублей. Они могут себе позволить эти решения и они им зачастую нужны. Но не используют. Потому что надо въезжать во все эти новомодные аббревиатуры, внедрять их, учиться им, объяснять руководству результаты и т.п. А зачем? Нормативка не требует, за инциденты не наказывают, эффективность никого не волнует. "И так сойдет", как говорилось в известном советском мультфильме.

Грустные размышления какие-то получились. Может я не прав? Может жду от безопасников чего-то чего не стоило бы? Фиг знает.

ЗЫ. Оказывается я про это два месяца назад писал, но другими словами :-) Наболело, значит. Ну да ничего. Повторенье - мать ученья.

ЗЗЫ. Дальше вернусь к темеSOCов.

Подробнее…

Как выбрать аутсорсинговый SOC?

Пора начать публиковать заметки по результатам прошедшего SOC Forum (материалы уже выложены), на котором я для себя выделил 5 категорий участников:

• Тусовщики, которые приехали пообщаться, поселфиться, отметиться, показать, что жив, или поискать работу.
• Потенциальные или существующие потребители услуг SOC, которые хотели понять, стоит им влезать в тему SOC или убедиться, что они делают все правильно, заодно переняв лучшие практики, которые звучали с трех сцен форума.
• Регуляторы, которые доносили до аудитории явно или неявно свою позицию по тому, как будет регулироваться тема мониторинга ИБ, SIEM, ГосСОПКИ, реагирования на инциденты и т.п.
• Продавцы продуктов для SOCов.
• Продавцы аутсорсинговых SOC, которые заманивали в свои сети ничего не подозревающих заказчиков, которым может быть SOC был и не нужен, но не по мнению поставщиков услуг мониторинга ИБ.

Вот последним и будет посвящена эта заметка. Сразу хочу сказать, что я ни в коем случае не хочу бросить тень ни на кого из поставщиков услуг SOC, тем более, что среди них есть очень достойные предложения и решения. Но выбрать среди них правильного партнера непросто. Критериев либо нет вовсе, либо они столь сложны в оценке, что мало кто может пройтись по чеклисту, чтобы оценить себя и представить результаты публике. А еще бывает, что отсутствует независимая методика оценки SOC (даже при наличии моделей зрелости SOC от HPE или Cisco) и каждый SOCостроитель оценивает себя как повезет. При средней оценки в отрасли 1.55 (при желаемых 3.0) я несколько раз слышал от отечественных SOC, что их уровень зрелости приближается к 4-м :-)

Фрагмент содержания отчета Cisco по оценке зрелости SOC

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

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

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

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

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

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

Подробнее…

Обзор тенденций ИБ-регулирования для телекома (презентация)

Вчера в 7 вечера внезапно узнал, что сегодня должен в 10 утра выступать на конференции РБК для юристов телекома с обзором развития законодательства по ИБ для операторов связи. В итоге родилась коротенькая презентация, которую и выкладываю:

Обзор тенденций ИБ-регулирования для телекома from Aleksey Lukatskiy

Подробнее…

Как готовить UEBA: рецепты от Гартнер

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

UEBA или User-Entity Behavior Analytics - это модная тема, к которой стали обращаться организации, не получившие удовлетворения от внедрения SIEM и иных инструментов анализа данных в контексте информационной безопасности. Немного повангую, предположив, что в России скоро может появиться мероприятие типа UEBA Forum, которое будет продвигать какой-нибудь отечественный вендор по ИБ. И ярким кандидатом на эту роль я бы назвал СерчИнформ, который сейчас “пилит” свою UEBA, называя ее системой профалинга пользователей. На самом деле об активности в этой сфере уже заявляли 4 компании - Инфовотч, Солар, СерчИнформ и ЦБИ, но:

• у Инфовотча уже есть DLP Russia (то есть BIS Summit)  “про DLP”
• у Солара есть SOC Forum “про SOCи”
• у ЦБИ есть конференция по мониторингу “про SIEM”.

Остается СерчИнформ, которому сам Бог я велел запустить такое мероприятие на волне огромнейшего интереса к фокусным конференциям по ИБ. Но хватит предположений, пойдем дальше…

В каких случаях компании обращаются к UEBA. Их по сути три:

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

Отсюда сразу вытекает вывод, что UEBA - это искусственно созданная сущность, возникшая на фоне проблем у существующих на рынке решений по ИБ, и когда эти задачи будут решены, то и само понятие “рынок UEBA” исчезнет (по возможным прогнозам - к 2020-му году), слившись с другими технологическими нишами, коих по-крупному выделить можно две:

• SIEM. Очень часто производители UEBA используют системы управления событиями ИБ как точку входа для своих аналитических возможностей. Оно и понятно - зачем самим собирать данные из источников, когда можно взять их уже готовые из SIEM. Но тут напрашивается вывод, что SIEM-вендоры могли бы расширить функционал своих продуктов, добавив в них UEBA. Так и поступают, например, Splunk, IBM, LogRhytm. Из отечественных игроков SIEM по этому пути пошел, как минимум, ЦБИ. Тут, правда, стоит оговориться, что UEBA отличается от классического SIEM тем, что не опирается на жесткие правила корреляции, пороговые и “средние” значения, которыми оперируют системы управления событиями ИБ. Все-таки в аббревиатуре UEBA последняя буква означает “advanced analytics”, то есть нечто более продвинутое, зачастую базирующееся на машинном обучении и иных интересных фишках, которые позволяют системе самообучаться, а не жить за счет правил, созданных аналитиком SIEM. Еще одним отличием от SIEM является работа с не “чистыми” ИТ-данными. Нередко UEBA берут информацию от HR-решений, бизнес-приложений, систем экономической безопасности и т.п., существенно расширяя оперируемый ими контекст.
• DLP. Учитывая, что DLP в последнее время все чаще трансформируются из средств защиты от утечек информации в средства мониторинга поведения пользователей (даже рабочее время контролируют), то логично предположить, что DLP будут расширяться функциями UEBA. По этому пути пошел СерчИнформ, Инфовотч, Солар. На мой взгляд это тупиковый путь (вот тут более подробно написано, почему), так как сама идея DLP обречена на неудачу в современной ИТ-среде, но, видимо, DLP-вендоров это мало останавливает и они хотят придать новый толчок своим продуктам с помощью хайповой UEBA.

Понятно, что помимо SIEM и DLP, технология UEBA может развиваться и самостоятельно. По такому пути пошли лидеры этого рынка - Securonix и Exabeam (у нас “чистых” отечественных UEBA-вендоров не наблюдается). Учитывая вышесказанное, не исключаю, что указанные компании будут куплены более крупными игроками и слиты с существующими продуктами. Гартнер считает, что UEBA-функциональность будет появляться и в других нишах ИБ - CASB, EDR, NTA, что еще острее поставит вопрос о необходимости UEBA как самостоятельного решения или выбору UEBA, как технологии в каком-либо из существующих на рынке продуктов.

Гартнер видит два бизнес-кейса для покупки UEBA:

• Улучшение обнаружения угроз, пропускаемых другими средствами защиты. Но есть ли у вас такие средства? Вы используете что-то помимо IDS/IPS и антивирусов? Вы применяете NTA, CASB? У вас уже есть SIEM и вы, имея многолетний опыт работы с ним, понимаете, что его возможностей вам реально не хватает? Это важный момент. UEBA нужна тогда, когда вы реально перепробовали все и вас это не устраивает. Вот тогда вы действительно готовы потратить кругленькую сумму денег на поведенческую аналитику. Если же для вас это очередной хайп и вы с трудом понимаете, что такое UEBA и зачем она нужна, то стоит повременить с выбором.
• Повышение эффективности повседневных операций по ИБ, позволяющих более оперативно детектировать компрометацию пользовательских учетных записей, утечки данных, нарушения привилегированных пользователей и т.п. Но тут вновь нас подстерегает засада. Вы вообще оцениваете эффективность своих операций по ИБ? Вы реально оценивали временные и финансовые затраты на их реализацию? Вы попробовали снизить их более простыми и, возможно, бесплатными методами? Может начать с этого? Вот если вы готовы с цифрами в руках показать, что текущее положение дел вас действительно не устраивает, вам стоит посмотреть в сторону UEBA. Но только в этом случае. В противном случае вы потратите много денег и так и не поймете, стало ли у вас лучше и “эффективнее”.

Среди некоторых ключевых проблем, с которыми сталкиваются заказчики, внедряющие или внедрившие UEBA, Гартнер называет следующие:

• Доступность и качество исходных данных. Да-да, спустя 20 лет с момента появления SIEM на рынке, это до сих пор основная проблема в мониторинге ИБ. Именно ей была посвящена конференция ЦБИ, о которой я писал в предыдущей заметке.
• Квалификация аналитиков. В прошлый раз, на семинаре Gartner в Москве, рассказывая про продвинутую аналитику, Антон Чувакин также касался этой проблемы. У вас есть на примете те, кого на Западе называют data scientist? Они должны хорошо разбираться в ИБ и математике одновременно, чтобы строить и проверять корректность используемых моделей поведения, закладываемых в решения UEBA. Зачастую найти таких специалистов почти нереально, а их годовой фонд оплаты труда может быть выше стоимости UEBA-решения. Без грамотных аналитиков приоретенное решение превратится в тыкву и станет очередной бесполезной игрушкой в руках службы ИБ.
• Оценка эффективности технологии. Ну я бы назвал это общей проблемой в ИБ, а не только в UEBA.
• Приватность. Да, работа с Большими данными - вообще представляет большую проблему для приватности, так по анализу разрозненных данных можно делать очень интересные, и часто нелицеприятные, выводы о поведении пользователей, что вступает в конфликт с конституционными правами граждан на невмешательство в частную жизнь. Антон рассказывал, что одного из американских UEBA-вендоров европейские заказчики даже попросили переименовать продукт, чтобы из его названия исчезли слова “user behavior analysis”, которые являются табу в Европе, так борющейся за права граждан. У нас, кстати, это тоже может скоро стать проблемой, так как Роскомнадзор готовит законопроект по так называемым большим пользовательским данным и регулированию деятельности по работе с ними. Он может коснуться и UEBA-решений (да и вообще анализа Big Data в контексте ИБ).

В заключении Антон Чувакин сделал достаточно важное замечание про будущее всех решений на базе продвинутой аналитики (advanced analytics). Безопасность - это всегда про умного нарушителя и какой бы супер-умной не была технология, она всегда будет сталкиваться с иррациональным поведением человека, которое сложно предсказывать. У автоматизированных систем принятия решений в ИБ (читай, ИБ-роботов) есть будущее, но нельзя полагаться на них целиком - роль человека в принятии решений остается очень важной. Поэтому, внедряя  UEBA, SIEM, SOC, EDR, NTA и т.п. не забывайте уделять должное внимание квалификации своего персонала, который внедряет, настраивает и эксплуатирует все современные “умные” ИБ-технологии.

ЗЫ. Кстати, мы внутри службы ИБ Cisco тоже используем UEBA-решение. Но, как это уже было с системой продвинутого анализа событий безопасности OpenSOC, мы не нашли устраивающего нас на рынке решения по ИБ (хотя и инвестировали 30 миллионов долларов в Exabeam) и в итоге написали собственную систему контроля поведения пользователей. Как нибудь я расскажу об этом решении, также как я уже описывал систему OpenSOC.

Подробнее…

5 поглощений по ИБ - Qualys, McAfee, Trend Micro, Barracuda, Proofpoint

Что-то замотался и не успел написать про последние поглощения на рынке ИБ, а их оказалось много - аж целых четыре:

• 29 ноября Qualys анонсировала приобретение активов NetWatcher, которые позволят Qualys усилить свою экспертизу в области обнаружения атак, поведенческой аналитике, реагировании на инциденты, SIEM и управлении соответствием требованиями по ИБ. Размер сделки не сообщается. Насмотрелись на Positive? :-)
• 8 ноября Barracuda объявила о покупке частной компании Sonian для усиления своих решений по защите электронной почты, а спустя три недели, 27 ноября, купили уже саму Barracuda. Это сделан инвестиционный фонд Thoma Bravo, который специализируется на покупках ИБ-компаний. Размер сделки составил 1,6 миллиардов долларов.
• 27 ноября McAfee объявила о намерении купить одного из участников рынка Cloud Access Security Broker (CASB) - компанию SkyHigh. Сумма сделки не раскрывается. Почти всех игроков рынка CASB раскупили.
• 27 ноября Trend Micro объявила о покупке канадской Immunio для расширения своего портфолио по безопасности гибридных облаков. Размер сделки не сообщается.
• 29 ноября Proofpoint, которая месяцем раньше купила Cloudmark, объявила о намерении купить за 60 миллионов долларов WebLife, занимающуюся технологиями изоляции браузеров для защита корпоративных пользователей Web-почты.

Подробнее…

Обзор конференции ЦБИ по мониторингу ИБ

Неделя с 16 ноября прошла под знаком мониторинга ИБ. Сначала пошло камерное мероприятие Гартнера, на котором Антон Чувакин рассказывал про системы поведенческой аналитики (UEBA), которые по версии этой аналитической компании относятся к набору обязательных для SOCов технологий. Спустя несколько дней прошел уже четвертый (третий в России) SOC Forum, который собрал какое-то неимоверное количество народа и поднял несколько очень важных тем, которым я еще посвящу несколько заметок. Но сейчас я бы хотел коснуться другого мероприятия, которое прошло накануне SOC Forum и которое было организовано ЦБИ.

Когда меня на него звали, я был достаточно скептичен. Абсолютно новое мероприятие, проводимое вендором, который запускал новый продукт (Neurodat SIEM), да еще за день до более известного SOC Forum... Но я ошибался. Во-первых, представители ЦБИ практически ни разу не прорекламировали свое решение по мониторингу ИБ. Другие выступающие иногда не стеснялись рекламировать свою компанию и свои продукты (несмотря на запрет от организаторов), а ЦБИ держал марку. Очень достойно это выглядело! Во-вторых, вместо предполагаемых ста участников зарегистрировалось 500, а пришло более 300! 300 человек, которым была интересна тема SIEM и мониторинга ИБ настолько, что они отдали ей предпочтение вместо SOC Forum, который должен был пройти на следующий день. И это лишний раз подтверждает мой давно высказанный тезис, что нам не хватает фокусных мероприятий, а не конференций "обо всем и ни о чем". В итоге мероприятие получилось очень насыщенным и интересным.

Хотя надо признать, что местами некоторые доклады выглядели немного по-детски что ли. Я уже как-то писал, что свою первую SIEM я внедрял в 99-м году, в одном из киевских банков. Тогда, почти 20 лет назад, уже активно обсуждались вопросы по источникам данных, корреляции событий, log management и другим базовым вопросам при создании, внедрении и эксплуатации систем мониторинга ИБ. И, что местами выглядело странно, сейчас вновь обсуждаются эти же вопросы, а ответы на них преподносятся как открытия, достойные Нобелевской премии. Но многие из этих проблем и задач известны давно и на них уже даны ответы. Почему надо изобретать велосипед?

Ну да ладно. Хочу отметить несколько важных моментов, которые прозвучали на конференции:

• Почему сейчас все заговорили про мониторинг? Я этим вопросом задавался на прошлогоднем круглом столе по SIEM и продолжаю задаваться сейчас. Вроде требования по мониторингу у ФСТЭК появились еще в 2013-м году (блок требований РСБ). У ЦБ в СТО БР они тоже были давно. Что послужило причиной такого хайпа вокруг мониторинга? ФЗ-187 о безопасности критической инфраструктуры? Тема SOCов, которая тоже высосана из пальца? Возможно. В любом случае такое внимание к этой теме вызывает вопросы, особенно на фоне отсутствия сколь-нибудь серьезно выстроенной инфраструктуры ИБ у многих заказчиков, которые фокусируются преимущественно на периметре и установке антивирусов на ПК. Про это, кстати, говорил и Виталий Лютиков из ФСТЭК, повторяя тезисы, которые он озвучивал еще 2 года назад на первом SOC Forum. Зачем нужна SIEM или SOC, если в организации нет достаточного количества средств защиты информации? Почему все так ринулись в мониторинг, не имея того, что мониторить? Риторический вопрос, который, однако, заставляет задуматься, а реально ли нужно начинать строить систему защиты с SIEM? Решит ли она все проблемы?

• Тема SOCов очень модная и про нее говорят многие, активно выбирая или предлагая услуги по мониторингу ИБ в контексте ФЗ-187 (почему это глупость, я напишу в заметках про SOC Forum). Но многие забывают, что SIEM - это одна из основ SOCа. Первый SOC Forum был очень сильно ориентирован на SIEM-тематику, но потом как-то эту тему замылили, решив, что все настолько продвинуты, что можно говорить уже только о центрах и реагировании на инциденты. Увы. Часть обсуждаемых на конференции ЦБИ тем, показала, что многие просто не готовы к SIEM. Кто-то не имеет выстроенного процесса log management. Кто-то внедрив SIEM, забывает про внедрение системы единого времени (даже на базе NTP, не говоря уже о GPS или более патриотичном ГЛОНАСС). Кто-то забывает учесть разные часовые пояса, в которых находится система мониторинга и системы, которые мониторятся. Кто-то, говоря об источниках данных для SIEM, говорит только о логах, напрочь забывая про потоки (NetFlow) и поведение пользователей. Кто-то, заявляя о захвате/сборе всех данных в свои SIEMы, не может ответить на вопрос о последующей доступности контролируемых устройств в такой ситуации (нагрузка может быть настолько большой, что контролируемый узел просто уйдет в даун). Кто-то внедряет вторую SIEM только для целей ИБ, не умея или не имея возможности договориться с ИТ, которые уже внедрили другую систему мониторинга для своих целей. Вообще таких вопросов, показывающих уровень зрелости заказчиков применительно к SIEM, было много.

• На вопрос некоторым заказчикам, что их не устраивает в отечественных средствах защиты для целей интеграции с SIEM или SOC, услышал ответ, что "закрытость". Отсутствие сколь-нибудь развитых API, позволяющих интегрировать отечественные средства ИБ с системами мониторинга ИБ. А ведь по версии Gartner, которая опросила большое количество заказчиков по всему мира, именно открытый API и доступ к логам являются сегодня одним из обязательных признаков современного ИБ-вендора. 
• Очень забавной выглядела неразбериха с термином "мониторинг". Тут и докладчики, и заказчики были кто во что горазд, что показывает совершенно разный взгляд и уровень зрелости на данный вопрос. Например, Владимир Голованов из "Кристалла" рассматривал мониторинг не с точки зрения только сбора событий от средств защиты, как это делало большинство. Поэтому упоминание стандартов уровня ISO/IEC 27004 или ISO/IEC 15939 в его выступлении выглядело вполне логичным и понятным, хотя в соцсетях такая трактовка "мониторинга" и вызвала у некоторых экспертов вопросы.

         

• Кто-то опускался на уровень отдельных программ и говорил, что применение SysMon или RegMon или ProcMon от Sysinternal - это тоже мониторинг ИБ (и с этим сложно спорить). Кто-то приравнивал мониторинг к SOCу, а кто-то к SIEM. Разработчики DLP рассматривали мониторинг в контексте обнаружения утечек, что, наверное, тоже верно, но скорее всего расходилось с первоначальной идеей организаторов мероприятия. Разброс точек зрения был колоссальный, что в очередной раз подняло вопрос о необходимости унификации понятий перед началом конференции, чтобы иметь некую единую точку отсчета. Это позволит задать некую общую границу, ниже которой опускаться участники не будут и будут оперировать схожими точками зрения при обсуждении и выстраивании своих докладов.

• Немного островатой оказалась дискуссия на тему поддержки русского языка в системах мониторинга. Я задал аудитории вопрос, кому является критически необходимой поддержка русского языка не столько в интерфейсе, сколько в генерируемых отчетах и описаниях атак. Поднялась всего одна (!) рука. Участник, ее поднявший, ответил, что его заказчики - это оборонка и там не все (мягко говоря) знают английский, чтобы работать с зарубежными SIEM-системами. Выступавший в модерируемой мной секции представитель Ростеха (а у них тоже полно оборонки) высказал противоположную точку зрения, сказав, что без знания английского языка специалист по ИБ не может считаться таковым (немного утрирую) и в Ростехе не является препятствием, что средства защиты и мониторинга "говорят" на языке супостатов. Дальше один из представителей заказчиков высказал "ожидаемую" мысль, что вообще-то в России есть ГОСТы 34-й и 19-й серии и они обязывают создавать программные продукты (и документацию к ним) на государственном языке, то есть на русском. На этом дискуссия и закончилась, так как она грозила перерости в склоку :-)
• Поговорили о правилах корреляции, что бывает нечасто на таких мероприятиях, больше "продающих" коробки, чем рассказывающих о том, как самостоятельно настраивать систему сопоставления различных событий безопасности из разных источников.

• Представителю Инфовотча задал вопрос, который парой дней ранее обсуждася в Фейсбуке - зачем интегрировать DLP и SIEM? Четкого ответа так и не получил. Единственное, что было озвучено, так это вырожденный кейс от одного из заказчиков, который требовал блокировать в СКУД пропуск сотрудника, замеченного в утечке информации (чтобы не успел убежать от карающей длани службы безопасности).
• В очередной раз подняли разговор, что регулятор должен более активно участвовать в установлении требований к мониторингу ИБ. Тут вам и стандарты по формату событий ИБ, и требования к SIEM, и требования к управлению инцидентами. И все, чтобы обязательно было :-) Регулятор в лице ФСТЭК в очередной раз высказал скепсис в отношении таких желаний. Я лично тоже не понимаю этого стремления вендоров получить от регулятора "скрижали", соответствие которым позволит улучшить продажи своих продуктов. Попытки разработать стандарты обмена событиями ИБ в мире предпринимались не раз, но успехом они так и не увенчались. Всегда (и часто быстрее выхода стандартов) появляется новый класс продуктов, который имеет поля, отсутствующие стандарты. И что теперь, переписывать стандарты при появлении каждого нового средства защиты? Отсюда и небольшое стремление к стандартизации, которая не успевает за динамичным рынком ИБ. Да, есть некоторые стандарты де-факто - syslog (хотя и он существует в куче разных модификаций), STIX/TAXII, NetFlow и т.п. Но они все "зарубежные" и я иногда слышу заявления, что нельзя использовать стандарты потенциального врага (!). Тогда получается что, разработка своего, чтобы затем писать за дополнительные деньги коннекторы к нему, а потом еще и шлюзы-трансляторы из отечественного стандарта в зарубежные? В целом, я достаточно скептично отношусь к идее переложить на регулятора этот вопрос там, где это не нужно (в ГосСОПКЕ нужно, а в требованиях к SIEM или SOC нет).

• Когда я в первый раз писал о конференции, я упоминал, что она является не только практической, но и научной, что выделяет ее на фоне того же SOC Forum или мероприятий Gartner. И наука действительно была представлена на конференции ЦБИ в лице представителей питерского СПИИРАН, которые делали доклады про перспективы корреляции событий ИБ и прогностические модели, которые могли бы быть применены при мониторинге ИБ. Первый доклад делал Игорь Котенко, который поделился своим взглядом на SIEMы нового поколения (и как я понимаю, разработанные подходы могут быть использованы в отечественных разработках), на подходы к проактивному мониторингу, основанному на ретроспективной ИБ, на анализе графов атак и на автоматизации выработки контрмер для систем мониторинга (что само по себе является проблемой). Что характерно, вместо чисто научных формул, которые часто бывает сложно понять на ходу, СПИИРАН даже создал программный комплекс, реализующий разработанную методику.

• При этом данный комплекс является достаточно прогрессивным, использующим различные технологии анализа и корреляции данных, в том числе построенные и на Больших данных. Кстати, на следующий день, на модерируемой мной секции “Future SOC”, выступал Сергей Рублев из ГК “Инфосекьюритисервис”, который рассказывал о практическом опыте построения собственного SOC на базе как раз тех технологий, которые были упомянуты Игорем Котенко в своем докладе (Spark, Scala и др.)

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

•  Но этот доклад от СПИИРАН оказалось достаточно тяжело слушать и воспринимать. Чего только стоит такая фраза “Семантическая связь между событиями безопасности на физическом уровне и конечными показателями безопасности, в которых может быть она выражена содержательно, не достаточно определена“. Что имелось ввиду, фиг разберешь…

• Наконец, в заключение был интересный доклад от Андрея Дугина из МТС, который поделился опытом снижение нагрузки на операторов SOC, которые были разбиты на 3 части - технические, процессные и организационные.

В заключение хочу еще раз повторить, что мероприятие ЦБИ мне понравилось - свежая для России тема, большой интерес, интересные доклады. Кроме того, ЦБИ выделился и еще одной темой - они открыли программу технологического сотрудничества и объявили о выделении грантов на разработки в области мониторинга ИБ. Вообще, это интересная тема, которая показывает, что компания не варится в своем соку и готова развиваться. Выделено три гранта - совместно с Microsoft Rus и SolidLab на разработку алгоритмов идентификации действий пользователей. Что же мне это напоминает? А, точно, UEBA :-) И хотя про поведенческую аналитику на конференции почти никто не говорил, данные гранты ЦБИ говорят, что они решили пойти по пути многих вендоров SIEM, которые оснащают свои системы сбора и анализа логов и иных источников информации новым модным инструментарием по контролю действий пользователей. Сейчас в этом же направлении идут еще разработчики как минимум трех отечественных и псевдо-отечественных DLP. Ждем в следующем году UEBA Forum? 

Год назад, на PHDays, где я модерировал круглый стол по SIEM, я готовил список вопросов к вендорам. Надо признать, что эти вопросы до сих пор остаются актуальными для любого производителя - отечественного или зарубежного. Стоит их задать либо поставщику, либо самому себе, чтобы понять, так ли нужна вам SIEM и нужна ли вам именно эта SIEM, которую вам предлагают. Разброс мнений, точек зрения и подходов, прозвучавших на конференции ЦБИ, показывает, что тема до сих пор актуальна и еще долго будет мучить специалистов по ИБ, которые будут пытаться найти ответы на интересующие их вопросы (тут, главное, не замыкаться на себе, а смотреть шире, в том числе и на зарубежный опыт). И это, кстати, говорит, что тема поднятая ЦБИ "на флаг" своей конференции, достаточно благодарна для того, чтобы в следующем году провести второй "SIEM Forum", а потом и третий :-) Тем более, что у Neurodat SIEM вполне интересные планы развития:

ЗЫ. На самом деле осенью в Москве было еще два мероприятия по мониторингу - традиционные VB-Trend от VolgaBlob и конференция Splunk, но я на них не смог присутствовать, поэтому и писать про них не буду.

Подробнее…