Андрей Янкин: Cобственный SOC – это единственный путь сделать инструментарий ИБ под себя

Интервью с Андреем Янкиным — руководителем отдела консалтинга Центра информационной безопасности компании ЗАО «Инфосистемы Джет» — продолжает серию публикаций «Индустрия в лицах».

Какими критериями, по вашему опыту, определяется готовность компании к созданию собственного SOC? В каких случаях можно однозначно сказать, что компания к этому готова?

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

Первое — уровень рисков ИБ, который сейчас присутствует. Как его оценить? Можно с помощью статистики: если проблема действительно актуальна, то организация, как правило,  знает о том, что за прошедшие 9-12 месяцев были инциденты, которые привели к потерям. SOC — это большие инвестиции, и не имеет смысла начинать его строить, если особых проблем нет. Уровень рисков ИБ также можно оценить, взяв данные по отрасли в целом. Есть отрасли более подверженные рискам: финансовая сфера, области, связанные с риском для человеческой жизни, например, крупная промышленность или авиация. А есть отрасли, которым риски ИБ, влекущие за собой серьезные последствия, менее присущи.

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

Третий, самый очевидный фактор — размеры ИT-инфраструктуры. Думаю, в общем случае здесь грань проходит в районе 10 тысяч узлов. Исключениями могут стать специфические случаи, такие как, например, платежные системы, банковские организации, некоторые государственные структуры, потому что в этих случаях «концентрация» рисков ИБ выше и строительство выделенного SOC может иметь смысл.

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

То есть для старта SOC в компании должно быть больше 10 тысяч узлов?

А. Я.: Я бы ориентировался на эту цифру именно IP-адресов. Считаем не сотрудников, а размер ИТ-инфраструктуры.

Какие отрасли все же наиболее заинтересованы в строительстве SOC в России?

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

Позволит ли создание SOC улучшить защиту, защититься от APT-атак или более эффективно с ними бороться?

А. Я.: Определенно, более эффективно бороться получится. Вообще что такое APT? Есть некоторые абстрактные исследования про китайских хакеров, АНБ и т.д., но для большинства организаций это неактуально, вторично. Хорошим примером APT-атак являются целевые атаки, которые массово идут на банки. О них отчитывается Центральный Банк: в отчете за первый квартал на один только АРМ КБР (прим. ред.: рабочее место клиента Банка России, через которое управляется корсчет Банка России) было 19 атак. Это для рынка и есть APT: проникновение в сеть через социальную инженерию, постепенное развитие атаки.

По статистике того же ЦБ, атака длится в среднем 3 недели, и как раз задача SOC - получить набор событий, отследить, соединить в единый инцидент и ему противостоять. С другой стороны, когда что-то плохое произошло, SOC должен сработать, как пожарная команда: моментально отреагировать на атаку. В случае с АРМ КБР у жертвы есть максимум 5 дней на то, чтобы заморозить деньги на счетах других банков, вернуть хотя бы их часть. Чем дольше персонал будет решать, что ему делать в критический момент, тем больше денег будет потеряно.

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

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

С точки зрения эффективного реагирования вопрос одним настраиванием технических средств действительно не решается, участвует вся классическая триада. Первое — формирование команды профессионалов, реальных практиков. Второе — выстроенные процессы: как люди должны работать, как взаимодействовать со смежными подразделениями и т.д. Третье — настройка технических средств, причем здесь я бы не ограничивался SIEM-системой. Это и датчики, например, IPS во всех своих проявлениях, это и вспомогательные инструменты. Например, строится свой сервис-деск с колл-центром, организуется взаимодействие с корпоративным хелп-деском. Необходимы инструменты анализа образцов вирусов, дампов трафика и т.д. Получается целый комплекс технических средств. Как у хирурга, инструментов в SOC необходимо много, и они все отточены и на своем месте.

Если вся эта триада дошла до определенного уровня зрелости, то можно говорить о том, что SOC функционирует и готов эффективно противостоять атакам.

Из вашей практики, если к вам приходит заказчик с разрозненным набором средств информационной безопасности и желанием их все объединить, чтобы получить свой SOC, сколько времени уйдет на то, чтобы прописать все процессы, создать необходимую документацию, технически все это объединить, настроить политики?

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

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

Обычно ожидается, что благодаря вложениям в ИТ-технологии нагрузка на персонал падает, а его эффективность растет. В случае с SOC, наверное, происходит наоборот, нагрузка растет?

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

Квалификация тоже должна быть выше у этого персонала?

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

Если переходить к экономической части, то каким образом можно оправдать перед владельцами бизнеса затраты на SOC? Можно ли здесь вообще говорить о модели расчета возврата инвестиций?

А. Я.:  Что касается расчета ROI в случае с ИБ в целом, зачастую это профанация. Чтобы правильно посчитать ROI, нужно столько ресурсов затратить… Поэтому чаще всего идут простым путем, в итоге считают какую-то абстрактную величину. Но в случае с SOC в определенных случаях такая возможность есть. В первую очередь, в финансовых организациях, где инциденты порождают прямую потерю средств клиентов либо самой организации. Соответственно, здесь можно посмотреть статистику по инцидентам, сделать некоторый условный множитель, получить конкретные потери, спрогнозировать эффект по снижению этих потерь и что-то обосновать. Плюс есть организации, которые исходят из других показателей, для них коэффициент ROI не актуален: те же промышленность или авиация. Катастрофа, которая может произойти в случае захвата контроля над их ИТ-системами — падение самолета, взрыв гидроэлектростанции — в рублях не измеряется, нет на сегодняшний день такой традиции в России. Обоснование вытекает из необходимости защиты от таких чудовищных событий.

Дополнительным аргументом для руководства является compliance (прим. ред.: Требования законодательства и отраслевых регуляторов). SOC целиком одной необходимостью соответствия требованиям регуляторов обосновать сложно, но дополнительные аргументы могут быть. Например, со стороны стандарта PCI DSS, или у ЦБ РФ есть довольно интересные требования.

Рано или поздно в организации встает вопрос, делать SOC у себя или отдать на аутсорсинг. В каких случаях делать самостоятельно выгоднее, а когда целесообразно отдать на аутсорсинг?

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

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

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

И еще один момент, который часто бывает важен для заказчиков, это CAPEX — OPEX. Если, например, компания дочерняя западной структуре и ей выделяется только OPEX (операционные расходы), то у нее нет выбора, она не может строить у себя новые подразделения, делать капитальные вложения.

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

Можно ли выделить категории заказчиков, для которых аутсорсинг в случае с SOC технически или  юридически противопоказан, никак не подходит?

А. Я.: Во многих организациях внутренними политиками запрещено передавать конфиденциальную информацию наружу. Security-логи по сути — крайне конфиденциальная информация, соответственно, во внешний SOC их передавать нельзя.

С точки зрения compliance, я бы сказал, что только государственная тайна (ГТ) является ограничением. Все, что касается банковских тайн, PCI DSS, ПДн, все это юридически решаемо.

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

Мы говорим о крупных компаниях-заказчиках — около 10 тысяч хостов. В России таких компаний не так уж много. На ваш взгляд, каково количество компаний, которые строят, построили или будут строить SOC в России? Возможно, ли дать оценку объему рынка в целом?  

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

Если говорить о выделенном подразделении, то сразу цифру назвать сложно. На вскидку это топ-40 банков, которые готовы вкладываться не просто в совершенствование своих процессов ИБ, а в выделение чего-то отдельного. Промышленники — сотня компаний, для которых эта проблема актуальна и они уже что-то строят, построили и идут этим путем. Отчасти крупный ритейл, компании финансового блока. Это не только банки, но и платежные системы, взять хотя бы Qiwi, к строительству SOC в которой мы тоже приложили руку. Но это моя личная экспресс-оценка.

Благодарим за беседу и желаем вам успехов!