Текст программы:

 

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

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

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

Так вот, обсудить эти непростые вопросы я пригласил представителей компаний, разрабатывающих и внедряющих инструменты автоматизации процессов в области ИБ. Приятно, что хоть в этом направлении у нас всё в порядке с импортозамещением, и все 3 компании действительно отечественные: с первой до последней строчки продукты made in Russia. Таких решений 3 в России. Это: «Jet InView», компании Jet Infosystems. Анна Костина(А.К.). Здравствуй, Аня.

А.К. Привет, Аркаш!

А.П. Компания R Vision, директор компании, Александр Бондаренко (А.Б.). Александр, здравствуй.

А.Б. Привет!

А.П. А также Security Vision, компания АйТи, Руслан Рахметов.(Р.Р.)

Р.Р. Привет

А.П. Также у нас на связи из Новосибирска человек, съевший не один пуд соли на построении SOC решений для его заказчиков. Это Никита Ремезов(Н.Р.), скажем так, сотрудник отдела информационной безопасности Совкомбанка. Никита, ты там?

Н.Р. Всем привет!

А.П. Отлично. Коллеги, давайте начнем. Тема сегодняшней программы у нас будет: «Подходы к построению СУИБ, процессы и их автоматизация». В прошлой программе мы обсудили с коллегами инструменты сбора и корреляции событий, автоматическое формирование инцидентов – это SIEM-решение. А вот, Руслан, а когда компания созревает и понимает, что от обычных SIEМ пора переходить к SOC?

Р.Р. Коллеги, на мой взгляд переход от SIEM к SOC очень логичен. И он, как ты, Аркадий, правильно сказал, связан с развитием компании, с развитием сотрудников компании, безусловно. Но, что интересно, это всегда происходит тогда, когда происходит какой-то инцидент. Тогда компания понимает, что какой-то процесс у нее страдает, и его нужно автоматизировать. Либо случается инцидент информационной безопасности, который SIEM не видела, не определила, и компания хочет больше аналитики. Переход к SOC очень логичен, это больше акцент на Network Security, именно сетевой безопасности. Если говорить о тех продуктах, которые делаем мы, я за ребят не скажу, это все-таки больше понятное для русского человека слово автоматизация СУИБов, то есть это больше относится к автоматизации СУИБов. Или там иностранное слово GRC — страшное.

А.К. Наверно, тут нужно разделять SOC и СУИБ, как такое понятие... Если все-таки мы рассматриваем связку SIEM и процесса управления инцидентами – все-таки это процесс управления инцидентами как один из процессов СУИБ.

А.П. Никита, у тебя есть мнение на этот счёт?

Н.Р. У меня есть.

А.П. Когда всё-таки созревает организация?

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

А.П. Ну, то есть удалять его? Или чего ?

Н.Р. Нет, это отреагировать. Чтоб у тебя на тот момент, когда, например, работал антивирус, ты не знаешь, сколько времени у тебя этот вирус работал уже, и что злоумышленники успели уже сделать. И тебе в этот момент нужно управлять антивирусом, логи, прокси, IPS и всего остального. И в тот момент, когда нам нужно гарантировать, что мы уложимся в 2 часа или 4 часа, 6, 8, это означает, что мы запустим какие-то процессы, процедуры. Начинает под это дело выделять время существующих людей или будем брать новых. В этот момент мы думаем о SOC.

А.Б. Я бы от себя добавил. Мне кажется, что мы очень много вещей сразу в одну кучу положили: SIEM, SOC, автоматизация, GRC, СУИБы. На самом деле это все настолько разные вещи. Как Аня правильно сказала, они еще и на разном уровне находятся, и поэтому мы, возможно, сейчас будем перебрасывать с одного блока на другой, и необязательно, что они будут между собой стыковаться. Если мы посмотрим на автоматизацию, необязательно должна быть совершенная и масштабная задача. До нее люди могут дозревать, если просто банально не хватает каких-то ресурсов на то, чтоб эту задачу выполнять в том виде, в котором она выполнялась раньше. Хороший пример в этом плане – банковская отрасль. После введения требований ЦБ России об отчетности регулярной по тем же самым инцидентам – причем эта область немного отличная от классического понимания SIEM-решения, который фиксирует некие технические инциденты. Дальше их нужно конвертировать на уровень отчетности в ЦБ, если это связано с какими-то платежными операциями. В крупных банках этому могут выделяться отдельные люди, которые будут заниматься этим практически каждый день, подготавливая отчетность, которая опять же к сожалению, не в самом удобном виде. И здесь, казалось бы, частная задача, конкретный кейс для автоматизации. Но это не GRC, и это не SIEM.

А.К. Это аналитика тех данных, которая поступает

А.Б. Это не совсем аналитика

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

А.Б. Да, в том числе. Я просто на этом примере хотел показать, что мы говорим прям об очень разных вещах. Либо нужно сузить как-то это попытаться до каких-то отдельных вопросов. Иначе боюсь, может получиться многосерийная Санта-Барбара.

А.К. У меня предложение немножко другое. Вот эти все понятия SOC-и, СУИБы, GRС, аналитика – как-то так сложилось, что они достаточно гибкие, и каждый раз под ними понимается что-то своё. Кто-то понимает под SOCом глобальный security operation центр, который включает в себя все про безопасность, а где-то это только управление инцидентами. Может, нам есть смысл выработать свое поле, что мы подразумеваем под этими понятиями и их использовать.

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

А.П. То есть это SOC?

Р.Р. Нет, Soc – это всё-таки больше network security, а СУИБы – это автоматизация процессов.

А.П. В них входит SOC?

Р.Р. В них входит SOC, появляется после SIEM. Тогда, когда компания хочет централизовать, сделать у себя единое location, единое окно какое-то. Возможно, включить туда SLA. Как Никита правильно сказал, чтобы иметь гарантию. Но это происходит, если отнестись к твоему первому вопросу, после инцидента, после кейса. Если у заказчика возникла ситуация, кейс, то компания приходит к тому, что ей надо вырасти до SOCа для того, чтобы иметь гарантированное время реакции по SLA, чтобы видеть в едином location, централизовать…

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

Р.Р. Ну, это кейс.

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

А.П. А этот процесс можно отдать на аутсорсинг вообще? СУИБ, SIEM,SOC можно отдать на аутсорсинг вообще? На сколько это логично будет, Александр?

А.Б. Я думаю, что лучше, наверно, Анна ответит. Потому что это у них как раз эта тема сейчас развивается очень активно. Если коротко, то SIEM и SOCи, наверно, да. Автоматизацию СУИБ – не уверен. Это моё мнение.

А.К. Если говорить про SIEM и SOC, как про некую автоматизацию плюс процессы, связанные с мониторингом, разрешением инцидентов и некими элементами расследования, то да, вполне. И как перевели стрелки, мы сейчас этим занимаемся, достаточно активно. Как Никита сказал, о чем задумываются люди, когда плавно переходят к идеи необходимости создания SOC, это необходимость – не важно, по каким причинам она возникла – отслеживать определенные события и инциденты, мониторить некие объекты инфраструктуры или бизнес-системы – ну, бизнес-приложения критичные. И реагировать на возникающие инциденты с некими уровнями – внутреннего или внешнего сервиса. И в этом случае, почему нет. Аутсорсинг, на наш взгляд, вполне возможен. Потому что когда люди осознали эту проблему, они сталкиваются, по сути, с 3 проблемами. Первое, это банальная нехватка людей. К сожалению, подразделения ИБ не так многочисленны и загружены и так, без создания SOC. А если мы говорим про нормальный хороший мониторинг, особенно если мы говорим про крупные компании критичные бизнес-приложения, есть по мере развития этой темы необходимость переходить на мониторинг 24/7, что влечет за собой многочисленные человеческие ресурсы.

А.П. Дорогостоящие.

А.К. Да. Вторая тема, с которой сталкиваются, это экспертиза. То есть должны быть люди с высокой экспертизой, которая реагирует на изменения тех угроз, которые происходят...

А.П. 24/7 ?

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

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

Н.Р. Я бы немножко разделил здесь свое мнение. Есть мнение, что всем нужно двигаться в эту сторону.

А.П. Попахивает проплаченной рекламой :)

А.К. Никакого сговора :)

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

А.П. Это твое личное мнение?

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

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

А.Б. Да-да, есть, конечно, требования. Я не уверен, что есть требования хранить их в банке. Я вот сейчас не могу вспомнить, чтоб было так жестко прописано, что нельзя никаким образом никуда передавать. То есть, в принципе, это допустимо. Единственное, я слышал скорее на неформальном уровне, про вообще полный аутсорсинг инфраструктуры, то есть когда полностью вся ИТ-инфраструктура находится в ведении сторонней компании. Особенно, когда аутсорсер какой-то заграничный, это Центральным банком не приветствуется. Но опять же прямого запрета нет. С формальной точки зрения, ЦБ требует отчётность. Она должна быть предоставлена и она должна быть достоверна, а как информация собрана, где хранится – не так важно.

А.П. А если всё-таки строить эти системы у себя. Руслан, по своему опыту, сколько сотрудников нужно для того, чтобы сам SIEM обрабатывать, и сколько сотрудников нужно для SOC? Минимум, максимум и оптимал. К чему готовиться людям, которые шагнут в эту сторону?

Р.Р. Мы отталкиваемся от сотрудников заказчика. Это всегда работа с людьми, мы хотим увидеть озарение в глазах озарение, и после этого только мы можем передать эту систему, чтоб они могли ее обслуживать. Поэтому требования к образованию и количеству... Ну, минимум это 1 человек всегда. Если это аутсорсинг, то результаты могут предоставляться вообще руководству напрямую. Но то, с чем мы сталкивались всегда. Аутсорсинг у нас всегда был практически неприемлем. Из опыта заказчиков ИТ, это связано, как Никита сказал с ментальностью, с тем, что когда у заказчика есть понимание развития SIEM, это уже какой-то базовый уровень заказчика, какая-то зрелость, когда заказчик понимает, что иб, и он ее боится передать кому-то. А тем более еще и аналитику с этой безопасности. Страшновато. Это возможно, но в силу ментальности, как Никита сказал - соглашусь.

А.К. По поводу ментальности. Это вопрос, который, наверно, больше сидит в головах. Потому что есть реальный пример одного из заказчиков, который откровенно поделился тем, как он шел к теме аутсорсинга мониторинга событий и инцидентов ИБ. Он очень высококвалифицированный специалист, и он говорит, что мне было трудно самому себе признаться, что я не смогу реализовать у себя вот именно такой, полноценный SOC

А.П. Что за уровень заказчика? Гос, коммерс, банк?

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

А.П. Количество людей, которое может управлять? Если без аутсорсинга, вот такой махиной.

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

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

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

А.П. 24/7?

Р.Р. Не 24/7. Все-таки система должна иметь возможность оповещения в случае необходимости, в вплоть до – инструментов оповещения очень много – можно и прожектор на окно навести. Смысл в том, чтоб эти люди были обучены в учебном центре, этому продукту, этому решению. Потому что мы делаем не коробочные решения, а кастомные решения, которые требуют адаптации под заказчика. Поэтому у специалистов должно быть в глазах просветление, как я уже сказал. Мы хотим, чтоб продуктом пользовались, чтоб он был ценным конечным продуктом, и чтобы люди могли это использовать. Поэтому оптимал – 2 человека.

А.П. Никита, ну хоть ты скажи, что нужно 5 человек: 2 аналитика, 3 оператора, которые должны нажимать кнопку.

Н.Р. Я именно это и собирался сказать :)

А.П. Вот! Человек! :) Давай всю правду матку!

Н.Р. Я же не интегратор. Для того, чтобы сделать что-то 24/7, нужно минимум 5 специалистов. Если исходить из простейшей математики - иначе не сойдется. Начиная с 6, оно хоть как-то будет устойчиво. Для моей организации 24/7 просто не нужно. Поэтому 5 на 8 с гарантированным временем реакции по 3 видам инцидентов. Этим у меня занимаются 2 человека по 50% своего рабочего времени и 3 - по 10%.

А.П. Обучение как проходило? Всех гонял на курсы? Все обучались? Все CCIE?

Н.Р. Одного человека я назначил главным технарем по решению – в данном случае мы говорим о SIEM. Мы отправили его на курсы, в итоге, он получил и практики различной. То есть, у него была и теория и практика. Он нам технически реализовывал то, что мы просили. Есть 2 парня, которые занимаются операционной частью. Им валятся все эти евенты, они их обрабатывают и начинают реакцию. И еще 2 человека: они периодически думают о том, как и что нам изменить и придумать.

А.П. Это аналитики, которые пишут бумажки одновременно?

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

А.П. То есть, по твоему опыту 5 человек минимум нужно для организации 24/7 такой системы мониторинга? У тебя задействованы 5 человек на схеме 5/8, а 24/7 получается еще больше людей?

Н.Р. Да, 24/7 – 5 человек. У меня эти люди занимаются еще массой других вещей. Не 100% времени посвящают тому, что смотрят события или анализируют и думают, что и как изменить наш SOC и SIEM.

А.П. А уровень образования какой должен быть? Что люди должны уметь?

Н.Р. Сейчас я сформулирую свой идеальный мир. Те ребята, которые смотрят: сетевик широкого профиля: с пониманием, как работают операционки и такие инфраструктурные решения, как прокси, базы данных, но очень непростого уровня, и которые умеют делать скрипты. Если у меня такой человек будет смотреть на ивенты, я буду 146% счастлив. И мне бы, в идеале, нужно 2 аналитика. Один безопасник, с образованием по ИБ с чистым опытом, а второй – человек DevOPs, который находится на стыке разработки и системного администрирования. Зачастую в организациях такие спецы занимаются автоматизацией различной, интеграцией, изменением конфигурацией различных систем. Человек, который может заскриптовать серьезные изменения в системах.

А.П. Понятно. Если мы от банков подойдем к банкам :) Александр, расскажи, пожалуйста, сталкивался ли ты с построением этих систем не в финансовых компаниях. В чем отличия построения SOCoв для банковских компаний, телекома, госов, медучерждений, промышленных, добывающих и др. Есть ли координальные различия в подходе построения? Или берешь ISO 27001 и вперед?

А.Б. Ну, смотри. Опять же, если мы говорим про SOCи – это одно. А если мы говорим про СУИБ, автоматизацию и про такие верхнеуровневые процессы менеджмента. Понятно, что если организация выбирает ISO 27001, то несмотря на то, что специфика какая-то есть, то всё равно будет много похожих вещей, просто потому что это приписывает стандарт. Хотя и 27001 не такой уж и строгий. А вот если мы говорим про SOC, то фокус у компаний разных, то на что они обращают внимание, и за чем они в первую очередь следят. Финансовые организации - это фокус к финансовые транзакции и системы, связанные с финансовыми транзакциями. Если мы говорим про медицинские учреждения...не знаю, в нашей стране, пожалуй, это...

А.П. Одно. ФОМС

А.Б. Я даже не готов это комментировать. Насколько у них вообще есть какие-то движения в сторону ИБ. У меня опыта нет.

А.К. Комплаенс по законодательству - это основной акцент с точки зрения ИБ.

А.Б. Ну да. У телекомов у них другая вещь: у них трафик, DDos. То есть, на уровне SOC – да, абсолютно различные требования и конфигурации. А на уровне менеджмента, СУИБ, автоматизации процессов – все как раз похоже.

А.П. Коллеги, очень много слушателей жалуются, что после 30 минут прослушивания подкаста, многие уже подъезжают к подъезду, стоят в наушниках перед дверью и думают: когда уже закончится этот подкаст, чтоб я уже зашел домой. Давайте сделаем маленький перерыв и разобьем эту программу на 2 части. Услышимся с вами в следующей программе.