Уберизация SOCов

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

Итак, представим, что нам нужно добраться из точки А в точку Б на автомобиле. У нас есть три возможности:

• Собственный автомобиль. Удобный и полностью контролируемый способ передвижения. Но и самый дорогой из всех.
• Аренда автомобиля, например, через Яндекс.Драйв. Этот вариант дешевле собственного авто, но бензин вы оплачиваете сами и водить вы будете самостоятельно (или надо нанимать водителя). Яндекс.Драйв предоставляет. вам только средство передвижения, не более того. Все остальное - ваша прерогатива.
• Услуга такси, например, через Яндекс.Такси. Вы просто заказываете такси, которое приезжает и отвозит вас, куда скажете. Вам ничего не надо делать, только сделать заказ и оплатить его.

Если посмотреть на российский рынок центров мониторинга ИБ, то у вас только две альтернативы, - построить SOC самостоятельно или заказать услугу в аутсорсинговом SOCе. В мире же рынок SOCов выглядит немного иначе - помимо указанных двух вариантов предоставляется еще и третий, аналогичный Яндекс.Драйву. Вы обращаетесь к компании, которая сдает вам платформу для управления SOCами в аренду. То есть вам не надо покупать SIEM, IRP/SOAR, TIP и другой инструментарий SOC, но при этом аналитики должны быть ваши, как и выстроенные процессы, playbook, runbook и т.п.

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

Если возвращаться ко всем трем вариантам, то у каждого из них есть свои преимущества и свои недостатки. Но в вариантах "Яндекс.Драйва" и "Яндекс.Такси" важно понимать, что услуга может быть оказана по-разному. Вспомним,  что у Яндекса есть несколько пакетов оказания услуги - Эконом, Комфорт, Комфорт+, Бизнес, Премиум. Многие берут первое из-за экономии. Но тогда без претензий по качеству. “Дорогу покажешь, дарагой” - такого уже почти нет (благодаря Яндекс.Картам), но слушать радио “Восток” всю дорогу и смотреть как водила чатится с кем-то, попутно еще и руля, стремно. Стоит ли экономия таких рисков?

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

Опыт работы не требуется! И вот такие люди будут заниматься мониторингом вашей ИБ. А вы ведь ждете от них квалификации, многолетнего опыта, выдачи вам рекомендаций, а не тупого следования вашим просьбам и распоряжениям (это, кстати, касается и проектировщиков SOC). Когда происходит инцидент ваш аутсорсер будет ждать, когда произойдет компрометация и тогда будет реагировать, или он обладает offensive-навыками и может предсказать, что будет делать хакер дальше, и сможет вовремя остановить его? За что вы в итоге платите - за профессиональный центр по ИБ или за дорогую справочную службу? 

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

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

Как НЕ надо выбирать SIEM?

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

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

Не выбирайте SIEM, потому что это модно

Ну это вроде и так понятно. Выбирайте не то, что модно, а то, что нужно. Это простая истина применима не только к SIEM, но и вообще к любому хайпу - от SOCа до блокчейна, от WAF до CASB. Для этого вам, правда, нужно знать, что нужно :-) А поняв это, вы поймете, как этого достичь и, только потом, сможете определиться с инструментарием для этого.

Не выбирайте SIEM под требования регуляторов

Регуляторы, и ФСТЭК, и ФСБ, и ЦБ, сегодня много говорят про необходимость непрерывного мониторинга ИБ и устанавливают требования к решениям этого класса. Особенно важно это при интеграции вашей инфраструктуры мониторинга с той же ГосСОПКА или ФинЦЕРТом. Но... обратите внимание, что иногда гораздо проще и лучше - строить систему мониторинга такой, какой ее хотите видеть вы (исходя из ваших условий), а на стыке с ГосСОПКОЙ или ФинЦЕРТом поставить какой-нибудь шлюз, который будет посредником между вами и регулятором и просто передавать нужные данные туда и обратно. Не ведитесь на рекламу ряда отечественных вендоров, которые говорят, что у них встроенная поддержка взаимодействия с ГосСОПКОЙ "из коробки". Зато другой функционал, который вам и нужен в первую очередь, там может быть не очень. В конце концов, если выбранный вами SIEM из-за "печати" "Approved by GosSOPKA" не сможет видеть инцидентов, то и отдавать вам будет нечего. А вот функция "генерация отчетов о соответствии требованиям регуляторов" очень неплоха; главное, чтобы эти отчеты были по регуляторике, которая применима к вам. В любом случае помните, решение по безопасности нужно для обеспечения вашей безопасности, а не требований регуляторов.

Не выбирайте SIEM, потому что вы строите SOC

Все умные люди, говоря о SOCах, обычно делают знак равенства между двумя фразами "имею SOC" и "имею SIEM", но это не совсем так. Достаточно просто вспомнить, что вы можете аутсорсить свой SOC у внешнего поставщика услуг, к которому вы предъявляете требования по скорости реакции, гарантиям, охвату вашей инфраструктуры, но точно не по тому инструментарию, который он должен использовать. Это его прерогатива, раз уж вы выбрали его из множества аутсорсинговых SOCов; доверьте ему и выбор SIEM. Вы вообще можете не знать, какой SIEM у вашего SOC-as-a-Service; вы же платите за услугу с понятными входными и выходными данными и вам не так уж и важно, что у нее внутри.

Не выбирайте SIEM, потому что он в правом верхнем углу магического квадранта

Обратите внимание, я не говорю, не выбирайте SIEM из этого угла квадранта. Я говорю, не выбирайте, потому что он там. Чувствуете разницу? Если SIEM попал в этот угол, значит он достаточно хорош (а вы же хотите все самое лучшее, не так ли?). Но вам нужна не медаль на грудь и не "мировой рекорд",  а решение стоящих перед вами задач. Возможно вас устроит что-то более простое и не столь дорогое? Возможно 50% функционала самого крутого SIEM в мире вам просто не нужны? Так зачем за нее платить (а также за специалистов, которые знают как работать с самым крутым SIEM в мире)?

Не выбирайте SIEM, потому что вас зачморили коллеги и говорят вам "Ты что, с Урала?"

Помните советский фильм "Самая обязательная и привлекательная"? Там был эпизод, где главную героиню привели к, как сейчас модно говорить, байеру, который предлагал то одну модную штуку, то другую, то третью. А на изумленный вопрос героини "А зачем это?", ее сравнили с деревенщиной, припечатав, ставшим классикой, "Ты что, с Урала?" Не выбирайте конкретный SIEM и вообще SIEM, потому что это модно и у всех ваших коллег это есть.

Не выбирайте SIEM, потому что вам надо выстроить сбор логов

Для сбора логов выбирайте решение соответствующего класса -  SIEM тут будет избыточен. Если, конечно, у вас нет четкого плана продержаться на вашем текущем месте еще лет пять, на которые у вас уже есть стратегия развернуть полноценный мониторинг ИБ, с долговременным хранением, корелляцией, оркестрацией, контролем поведения, анализом сетевого трафика и т.п. Если вы не имеете персонала, который будет пялиться в монитор SIEM круглые сутки или хотя бы в режиме 5х8 или если у вас нет задачи оперативного реагирования на инциденты (а ее может и не быть), то зачем вам SIEM? Ограничьтесь обычным LM-решением.

Не выбирайте SIEM по фичам и обещаниям вендора

Часто, смотря материалы вендоров, мы попадаем в ловушку "kill feature", которая означает, что у продукта есть какая-то классная фишка и вокруг нее выстроен процесс продаж. Помните анекдот про студента, сдающего экзамен по зоологии, который успел выучить только билет про блох? Вот так и тут. Например, у SIEM классная фишка - он по умолчанию интегрируется с ГосСОПКА, а вы, как субъект КИИ обязаны это сделать. И вот вокруг этого начинаются танцы продаванов с бубном, уводя вас в сторону от такой, например, проблемы как низкое количество событий в секунду (EPS), которое может обработать одна нода SIEM. И чтобы работать в вашей организации вам нужно поставить 4 ноды, в то время как у другого SIEM, у которого нет встроенной "килфичи" работы с ГосСОПКОЙ, достаточно всего одной ноды, да еще и с запасом.

Или другой пример. Продавец SIEM вам говорит, что вы сэкономите, купив его решение, так как у него SIEM и SOAR и IRP - все в одном флаконе. А вы же понимаете, что хотя бы IRP, но вам нужна (а может и SOAR вместо IRP). Вы берете этот SIEM, но потом оказывается, что он не работает в multi-tenant архитектуре, а у вас холдинг и каждому предприятию нужен свой "кусок". Или multi-tenant поддерживается, но нет иерархии SIEM "главный-подчиненный", которая вам нужна для охвата 9 часовых поясов и размещения нескольких центров мониторинга по России и странам СНГ, в которых у вас размещены точки присутствия. Смотрите сначала на архитектуру, а потом на конкретные функции, тем более обещаемые.

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

Не выбирайте SIEM, потому что он поддерживает искусственный интеллект

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

От ответов на них зависит, понимает ли вендор, что такое ИИ и машинное обучение в частности или нет? И стоит ли вестись на всю эту хайповую тему с магической заменой кучи конструкций "IF THEN" в коде или корреляционном правиле на словосочетания "искусственный интеллект", "нейросеть" или "глубокое обучение". Для того, чтобы назвать атакой 3+ попыток неудачного входа в систему с одной учетки за короткий интервал времени, много ума не надо. В отличие от идентификации кражи учетной записи по определению нетипичного места входа в систему, опираясь на результаты кластеризации таких попыток за большой интервал предыдущего времени, опираясь именно на ваши данные. ИИ в SIEM есть и он может решать свои задачи - вопрос в том, знаете ли, как выжать максимум из него, и знает ли это локальный поставщик?

Не выбирайте SIEM, потому что у него отличная корреляция

Это древняя песня, которую я помню еще с конца 90-х годов, когда внедрял свой первый SIEM в одном из национальных банков на постсоветском пространстве. Заказчик тогда тоже купился на рассказ про корреляцию и вот это вот все, но реальность была совсем другой. Несмотря на наличие правил корреляции "из коробки", которыми так кичился вендор, пришлось писать много своей логики, отличавшейся от задумки производителя. И это при том, что число источников, подключаемых к SIEM, было на порядки меньше, чем у современных решений по мониторингу. По рынку ходит цифра, что сколько бы правил корреляции в вашем SIEM не было, только 20% их них можно применять безболезненно. Поэтому надо четко осознавать, что писать правила корреляции под ваши use case придется вам (или внешнему интегратору за дополнительные деньги) и все слова о "уникальной системе корреляции" превратятся в реальности в тыкву.

Не выбирайте SIEM, потому что он имеет универсальный коннектор ко всему

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

Не выбирайте SIEM, у которого нет плана развития

Я уже писал выше, что надо проверять все заявленные и нужные вам фичи в рамках пилота. Не менее важно, чтобы у SIEMа был четкий план развития (с соответствующими подтверждениями), который учитывает тенденции рынка и вашу стратегию развития. Возможности масштабирования, рост производительности, новые коннекторы для интеграция с различными решениями (не забывайте учитывать все скрытые затраты такой интеграции, которые лягут тяжким бременем на ваши плечи), поддержка каких-либо стандартов (от STIX/TAXII и MITRE ATT&CK до ГосСОПКИ и ФинЦЕРТа), новые функциональные модули, новые корреляционные возможности, обнаружение новых атак и т.п. Вроде бы очевидные вещи, но часто бывает так, что продукт берется ради сиюминутных задач, а потом оказывается, что вендор и не развивает свой продукт, делая только косметические правки, оставаясь на позади конкурентов. Такое было в свое время с netForensics - лидером рынка SIEMов, который сдулся и прекратил свое существование. Кстати, план развития тоже не гарантия, что продукт будет развиваться согласно ему. Но это уже ситуация, которая не предсказуема и с которой приходится просто мириться, на ходу меняя решение на другое.

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

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

Не выбирайте SIEM, потому что у него харизматичный лидер с горящими глазами

Проверьте, что за этим лидером есть команда, которая готова развивать и поддерживать продукт. Извините, никто не вечен и все может произойти в жизни - от рождения детей до попадания в ДТП на "джихад-такси" Яндекс.Такси. Горящие глаза и делающие руки - это классно, но любая разработка - это процесс, который не должен зависеть от одного винтика, вынув который, все ломается. К иностранным вендорам этот совет малоприменим, а вот в России такие случаи бывают. 

Не выбирайте SIEM, потому что он поддерживает ваши средства защиты периметра

Первые SIEM появились в конце 90-х годов, чтобы сократить число ложных срабатываний у систем обнаружения вторжений и межсетевых экранов. С тех пор число источников событий безопасности и объем этих событий возросли многократно. Насколько выбираемый вами SIEM способен работать с такими источниками? DLP? CASB? AWS CloudTrail? Azure Monitor? UEBA? EDR? HRM? СКУД? SCM? ERP? СУБД? Иные бизнес-системы?

Не выбирайте SIEM, у которого нет реагирования

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

Не выбирайте SIEM, если не знаете, где взять людей для работы с ним

Очевидно.

Не выбирайте SIEM, если у вас нет процесса мониторинга ИБ

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

• Что вы хотите собирать?
• Где это находится?
• Кто отвечает за эти источники?
• Как и в каком формате хранятся эти данные?
• Как отдаются эти данные?
• Что надо предпринять, чтобы забрать эти данные?
• Как обеспечивается целостность и непротиворечивость этих данных?
• Что вы будете делать с этими данными?
• Сколько надо хранить эти данные?
• Какие виды анализа вы будете проводить над этими данными? 
• Как вы управляете временными метками в вашей инфраструктуре?
• Кто имеет доступ к этим данным?
• Насколько структурированы эти данные?

Вот только небольшой список вопросов, на которые надо получить ответы до начала выбора SIEM.

Не выбирайте SIEM с непонятным TCO

По результатам общения с вендором вам все понравилось и вы готовы заплатить кругленькую сумму за систему мониторинга событий ИБ. Но... посчитайте TCO для него. На тестах оказалось, что вам нужна иная конфигурация, чем вы изначально рассчитывали? Вам нужна лицензия на большее число EPS, чем думали изначально? Выбранное или рекомендованное вендором железо "не тянет" и требуется более мощное? Ваша архитектура потребовала новых коллекторов? Курсы обучения по SIEM в России не проводятся и надо ехать в Европу (а вас по приезду развернули, потому что вы под санкциями, несмотря на полную предоплату, - реальный случай)? Вы не учли размер хранилища под собираемые события ИБ (кстати, вы в курсе, что будет, если на ваш SIEM подадут больше EPS, чем надо, или база переполнится?)? Вы не заложили стоимость написания коннекторов под ваши специфические источники? Есть вендора, которые предлагают к своим решениям полную калькуляцию всех статей расходов, которые могут понадобиться для развертывания и эксплуатации SIEM с расчетом на 12, 24 или даже 36 месяцев. Ваш вендор вам такое может сделать с учетом вертикального (число EPS) и горизонтального масштабирования (число и типы источников)?

 Не выбирайте SIEM-вендора - выбирайте SIEM-партнера

В отличие от МСЭ, EDR, NGIPS или SIG, решение по мониторингу событий ИБ требует гораздо более тесного взаимодействия с его производителем (тоже можно сказать и про DLP, и про другие прикладные ИБ-игрушки). Это не коробка, которая работает по принципу "поставил и забыл". Работы с новыми источниками, понимание методов анализа, разработка правил корреляции, масштабирование, расчет TCO, обучение модели ML... Да мало ли еще тем, по которым вы будете постоянно общаться с производителем вашего SIEM. Готов ли вендор к этому? Готовы ли вы к этому?

 Не выбирайте SIEM как самодостаточную систему

Как вы будете использовать SIEM? Это важный вопрос. Не для чего, а именно как. Вы планируете ее использовать как самодостаточное решение или интегрировать с IRP/SOAR, TIP, NTA, UEBA, EDR, CASB, CMDB и другими решениями, которые вместе позволят выстроить вам цикл управления инцидентами в вашей инфраструктуре? Если второе, то смотрите на то, с чем и как может интегрироваться выбираемый вами SIEM.

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

О сертификации NGFW - текущий статус

В январе я написал заметку о том, что согласно новым подходам ФСТЭК, сертифицировать многие зарубежные средства защиты будет скоро невозможно. В апреле я продолжил тему, когда ФСТЭК выпустила письмо, требующее до 1-го января 2020 года (осталось 4 месяца) обновить все действующие сертификаты и подтвердить соответствие требованиям по доверию. И вот сейчас, спустя 4 месяца после последней заметки я хотел бы обновить тему и написать о текущем статусе сертификации NGFW.

Несмотря на кочующий из доклада в доклада, из статьи в статью, тезис о том, что 100% организаций имеют межсетевой экран и антивирус, в реальности все-таки речь обычно идет не об обычном МСЭ, а о межсетевом экране следующего поколения (NGFW), задача которого не только фильтровать трафик на прикладном уровне, но и распознавать приложения и осуществляемые внутри них действия, применяя к ним соответствующие политики, блокировать атаки, нейтрализовывать вредоносный код, предоставлять функцию VPN и контролировать доступ в Интернет, беря на себя функцию прокси. Это типовой функционал NGFW, который в зависимости от вендора расширяется песочницами, CASB, глубокой DNS-инспекцией, отражением DDoS-атак, WAF, сканером уязвимостей и т.п.

Как я уже писал в январе, чтобы получить по новым требованиям ФСТЭК сертификат на такой "комбайн", необходимо проверить весь функционал (хорошо, что ФСТЭК пока не требует, чтобы в NGFW функция VPN строилась на базе сертифицированных СКЗИ). Прошли те времена (хотя иногда раз-раз, да проскользнет мимо ФСТЭК такой сертификат) когда можно было получить для NGFW сертификат только по РД к МСЭ. Сегодня будь добр сертифицировать все - и антивирус (на соответствующий РД), и систему обнаружения вторжений, и WAF. А для того, для чего у ФСТЭК нет РД, будь добр прописывай проверку этих функций и среды функционирования в задание по безопасности. Весь непроверяемый функционал должен быть удален. Правда, в этом случае уже не приходится говорить о продукте класса NG, но это уже частности (кому-то важна именно бумажка, а не чистота процесса).

Все это была прелюдия, о которой я уже писал. Теперь пора посмотреть, что происходит у нас в части сертификации популярных в России NGFW по линии ФСТЭК (по линии ФСБ это и в голову никому не приходит). Не слукавлю, если скажу, что 99% всех NGFW, которые продаются в России, имеют иностранное происхождение. Специально не буду называть вендоров, но думаю, что их все и так знают. Так вот, общаясь с коллегами из всех этих компаний, но не называя имен, у меня сложилась сейчас следующая картина по состоянию сертификаций из NGFW:

• Один вендор вырезал из своего продукта часть основного (например, обнаружение приложений) и управляющего функционала (например, поддержку SSL, что поставило вопрос о работе с HTTPS, управлении по HTTPS и получении обновлений по нему же). В итоге NGFW превратился в обычный МСЭ (без приставки NG).
• Другой вендор, имея на NGFW-платформе, несколько вариантов ПО, сертифицирует только тот, который содержит только функционал МСЭ. Даже СОВ уже сертифицировать нельзя (это касается всех производителей), так как они все обновляются из-за рубежа, что по версии регулятора является угрозой ИБ.
• Третий вендор пытается запустить для России разработку особой ветки своего продукта, в котором от NGFW останется только FW, превратив его, да, в гораздо более удобный, чем российские МСЭ, продукт, но все-таки это уже не решение класса NG.
• Кто-то пытается скрыть свой NGFW в корпусе другого продукта, в котором еще установлен российский VPN, что якобы должно сделать продукт российским и обойти преграды при сертификации. Но судя по отсутствию сертификата, этот фокус тоже не прошел.
• Последний из иностранных вендоров и вовсе отказался от сертификации, понимая всю бесперспективность этого процесса для своего продукта.

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

А заказчикам стоит задуматься, им нужны шашечки или ехать? 

ЗЫ. Кстати, с сертификацией даже на 6-й класс сейчас тоже немало интересного происходит. Прописанный в требованиях ФСТЭК к доверию фаззинг - это то еще приключение, "карта" которого не понятна до конца даже регулятору, не говоря уже об испытательных лабораториях и заявителях. 

ИБ-фреймворки: какие бывают и зачем нужны?

На прошедшем "Код ИБ. Профи" еще одной активно обсуждаемой темой стали фреймворки, - о них рассказывал Илья Борисов, делавший обзор существующих распространенных фреймворков, и Андрей Прозоров, посвятивший свое выступление ISO 27001. Я решил тоже не отставать от коллег и поделиться своим взглядом на эту тему.

Я бы выделил три набора фреймворков, различающихся по своим задачам и цели применения - контрольные (от английского control, которое по-русски звучи длиннее - "мера защиты"), программные и рисковые. Большинство знакомо с первой категорией, которые представлены не только иностранными примерами - NIST SP800-53, горячая двадцатка CIS (бывший SANS Top20), а также отечественные документы ФСТЭК (приказы 17/21/31/239) и Банка России (ГОСТ 57580.1).

Эти фреймворки нужны для решения важных "технических" задач по ИБ:

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

Отличительной особенностью хорошего фреймворка являются группирование (тут почти все упомянутые выше примеры на высоте) и приоритезация защитных мер. А вот с последним пунктом в документах ЦБ и ФСТЭК есть сложности. Каталоги защитных мер обширны и насчитывают около двух сотен наименований, но как из них выбрать те, что дают максимальный эффект, особенно в условиях нехватки ресурсов на внедрение, непонятно. У уже не раз мной описанных австралийских требований по ИБ, например, есть такая приоритезация. Есть Топ4, Топ8 и Топ35 защитных мер, которые позволяют достичь 80%, 90% и 98% результата. Аналогичная функция есть и у NIST SP800-53 - против каждой защитной меры в поле "Приоритет" стоит значение от 0 до 3, означающих важность реализуемого мероприятия.

"Программные" фреймворки предназначены для:

• оценки текущего состояния программы ИБ на предприятии
• построения всесторонней (хотя это все-таки не совсем так) программы ИБ
• измерения зрелости программы ИБ и обеспечения возможности бенчмаркинга (сравнения себя с другими по отрасли).

Самым известным в Евразии и популярным фреймворком является ISO 27001, а в Северной Америке - NIST CSF. Первый интересен тем, что у него множество расширений под различные задачи. Например, есть ISO 27019 для энергетики, 27011 для телекома или ISO 27701 (совсем свежий стандарт) для персональных данных. В отличие от технических мер защиты, в ISO 27001 или NIST CSF меры носят более высокоуровневый характер - взаимоотношение с поставщиками, выбор средств защиты, управление активами, работа с персоналом, повышение осведомленности, управление инцидентами и т.п.

Часть этих мероприятий есть и в приказах ФСТЭК, но они все-таки ориентированы именно на техническую составляющую, чем на выстраивание программы. С ними можно построить и некоторое подобие программы, но для этого надо иметь достаточно большой опыт работы с документами ФСТЭК, - новичку это не удастся - многие пункты понятным далеко не всем. Да и процесс оценки текущего состояния или измерения зрелости программы ИБ по нормативным актам ФСТЭК невозможен. Я уже писал о возможных вариантах решения этой задачи, но они должны исходить от регулятора. ЦБ эту задачу решает лучше - у них скоро должен появиться еще один стандарт как раз по управлению ИБ на предприятию, который позволит и текущее состояние программы ИБ оценивать, и ее зрелость. 

Если первые два типа фреймворков хорошо дополняют друг друга, то третий имеет смысл применять только в очень зрелых компаниях, которые действительно понимают, что такое риски ИБ и знают как считать вероятность и ущерб (а это то еще приключение). В целом данный тип фреймворка, ярким представителем которого является FAIR или серия NIST, позволяет:

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

Резюмируя, хорошие фреймворки, опираясь на опыт уже множества внедрений и набитых шишек, позволяют сэкономить вам время и нервы, следуя описанному в фреймворке алгоритмы построения системы ИБ. Но не стоит думать, что вам нужен именно один из перечисленных выше фреймворков. По статистике Gartner 20% компаний разрабатывают собственный фреймворк, еще 16% дорабатывают существующие, а 20% - комбинируют компоненты из разных фреймворков. Еще 21% вообще их не используют вовсе, а 23% используют стандартные фреймворки (NIST CSF, ITIL и ISO 27001 входят в тройку самых популярных по версии NIST). 

Поэтому выбирайте то, что лучше подходит именно вам и именно под ваши задачи. Если вы государственный орган, то выбор у вас не богат - документы ФСТЭК и, возможно, ГОСТ Р ИСО/МЭК 27001 (сейчас как раз через ТК 362 проходит новая версия этого стандарта). Для финансовых организаций обойти ГОСТ 57580.1 (и последующие ГОСТы от ТК122) будет непросто. Остальные же имеют свободу выбора и я бы (если бы я выбирал), остановился бы на NIST CSF и NIST SP800-53. А если бы передо мной стояла задача выбора только контрольного фреймворка, то CIS Top20 у меня был бы на первом месте (или австралийский перечень).

ЗЫ. Практические аспекты по этим фреймворкам можно посмотреть в докладах с "Кода ИБ. Профи", которые скоро будут доступны на сайте (по подписке).

3 новых нормативных акта по ИБ для финансовых организайций

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

Платежных приложения Apple Pay и облачные ДБО должны быть сертифицированы

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

К двум новым субъектам ФЗ-161 теперь предъявляются новые требования в области кибербезопасности. Платежные приложения, которые используют операторы по переводу денежных средств должны соответствовать требованиям к защите информации при осуществлении переводов денежных средств. Можно было бы предположить, что под термин "платежное поручение" попадут и системы ДБО или "клиент-банк", но в законе и в своих разъяснениях Банк России дает понять, что речь идет только о тех приложениях, которые разработаны организациями, которые привлекаются кредитной организацией для проведения платежей. В пояснительной записке в качестве примера приводятся имена Apple Pay, Samsung Pay и MirPay. Опираясь на определение, я бы еще отнес к такого рода система и облачные ДБО, которые используют некоторые банки сегодня. Вообще это странная формулировка, так как требования 27-й статьи ФЗ-161 применяются к участникам НПС, а не к приложениям. Думаю, что тут речь идет о последних правках в 382-П, которые требуют сертификации платежных приложений на отсутствие НДВ или выполнения в их отношении анализа защищенности в соответствие с ОУД4.

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

Те, кто работает с МПС, обязаны выполнять требования ФСТЭК

2-го августа был принят 264-й ФЗ "Федеральный закон от 02.08.2019 N 264-ФЗ "О внесении изменений в Федеральный закон "О национальной платежной системе" и Федеральный закон "О Центральном банке Российской Федерации (Банке России)". Он направлен "против" иностранных платежных систем, заставляя их соблюдать требования, применяющиеся к российским платежным системам. Среди прочего в законе есть такой пункт: "Информационные системы операторов по переводу денежных средств, с использованием которых осуществляется прием электронных средств платежа и обмен информацией с иностранными поставщиками платежных услуг, информационные системы операторов услуг информационного обмена, с использованием которых осуществляется взаимодействие с иностранными поставщиками платежных услуг, должны соответствовать требованиям по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации." Иными словами, те системы кредитных организаций, которые взаимодействуют с иностранными платежными системами должны выполнять требования 235-го и 239-го приказов ФСТЭК независимо от результатов категорирования. Кстати, до 1-го сентября 2019-го года в ФСТЭК надо отправить перечень объектов КИИ.

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

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

Профиль защиты для платежных приложений

В 382-П, 683-П, 684-П, а также ГОСТ 57580.1 было требование о том, что платежные приложения должны быть сертифицированы в ФСТЭК по требованиям безопасности или в отношении которых проведен анализ уязвимостей на соответствие ОУД4. Вот собственно требования, по которым должна проходить сертификация, и прописаны в этом почти 150-тистраничном документе, проект которого выложен на сайте ТК122 (доступен только для членов технического комитета по стандартизации). Я не буду раскрывать подробности этого документа, но работа у разработчиков и испытательных лабораторий предстоит непростая и к 1-му января 2020-го года (этот срок прописан, как минимум, в 382-П) они точно не успеют провести сертификацию (там есть и иные препоны, связанные уже с самой системой сертификации ФСТЭК). Поэтому сейчас стоило бы воспользоваться оставшимися пятью месяцами и начал бы проводить анализ уязвимостей по ОУД4 (или требовать этого от разработчиков).

Вот такая тройка нормативных актов. И пусть на улице холодновато (в Москве, как минимум), то работка по реализации этих требований предстоит жарковатая... 

Пять уровней зрелости оценки ущерба от DDoS-атак на сайт организации

Понравилась мне прошлая заметка про ИБ для бизнеса на примере HR-подразделения. Она и дискуссии на прошедшем "Код ИБ. Профи" подтолкнули меня к идее данной заметки. На мастер-классе Рустема Хайретдинова зашел разговор о том, как можно показать влияние ИБ на бизнес, и прозвучал тезис о том, что бороться с угрозами не всегда необходимо, так как они не всегда интересны бизнесу. Этот тезис не нов, но дальше был приведен пример сайта, который подвергается DDoS-атаке, и который нуждается в защите... Или все-таки не нуждается?

Вроде бы любой безопасник должен защищаться от DDoS-атак, которые могут вывести из строя сайт компании. Но... нужно ли это бизнесу? И вот тут пригодится идея с пятью уровнями зрелости, которую я описал в прошлой заметке про ИБ и HR. На самом низшем уровне зрелости безопасник обычно вообще не думает об оценке ущерба от той или иной атаки, следуя принципу д'Артаньяна "я дерусь, потому что я дерусь", то есть "я защищаю, потому что надо защищать (или потому что так сказал регулятор"). К бизнесу это не имеет никакого отношения.

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

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

Многие виды бизнеса являются сезонными. Турагентства продают большинство путевок перед майскими, летними и зимними каникулами. Интернет-магазины также имеют сезонные всплески - перед Рождеством, перед Новым годом, перед 14-м и 23-м февраля, а также 8-м марта. Кроме этого, глупо думать, что посетитель, столкнувшись с простоем сайта, навсегда про него забудет и откажется от покупки. Он может прийти через 15 минут и совершить покупку. Он может позвонить по телефону в отдел продаж или написать по электронной почте, а потом продолжить цикл покупки снова через сайт. Поведение пользователя и цикл продаж - это два важных параметра, которые вам потребуется узнать у вашего коммерческого подразделения прежде чем вы снова возьметесь за калькулятор.

Но можно (а временами и нужно) пойти дальше. Помимо учета множества показателей, связанных с циклом продаж, профилем пользователя, временными спадами и пиками, размер средней сделки, количеством транзакций и т.п., мы должны также оценить финансовые показатели приобретаемого средства защиты от DDoS. Понятно, что эта сумма не должна превышать размер ущерба, но это совсем уж поверхностное суждение. Борьба с DDoS может быть представлена в виде облачного или on-prem решения (то есть продаваться по модели OpEx или CapEx соответственно). Купить такое решение можно поставив его на баланс, а можно воспользоваться лизингом. Оплата может быть произведена как за год использования (типичная схема для большинства средств защиты), так и помесячно или в пиковые интервалы продаж/спроса со стороны клиентов, а также по схеме "on-demand", то есть во время самой атаки. При этом последний вариант тоже может быть реализован по-разному - оплата "за атаку" или оплата "за полосу". И вот собрав воедино все финансовые, маркетинговые и айтишные показатели, можно уже заниматься расчетом ущерба от DDoS-атак и его оценкой применительно к конкретной организации. И только в этом случае можно говорить о том, нужна ли конкретному бизнесу защита от DDoS-атак или можно принять данный риск.

Обзор отчета SANS по Security Operations Center

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

• Чаще всего на аутсорсинг отдают пентесты и различные формы проверки защищенности организации (red/purple teaming). В остальном тенденции схожи с тем, что написано у Exabeam; с поправкой на то, что SANS оперирует абсолютными цифрами и практически не сравнивает ситуацию с предыдущим годом.
• Интересен был вопрос о том, как в SOC выстроен процесс управления знаниями, то есть документирование знаний, связанных с прошедшими инцидентами и операциями для ускорения процесса погружения в деятельность SOC новых его членов. Небольшие SOC используют неформальный процесс "один гигантский документ OneNote" или просто SharePoint. Большие SOCи используют для этих задач связку Jira с Confluence, которые позволяют вести базу тикетов и осуществлять накопление знаний в wiki-формате и обмен ими. SOCи, тесно связанные с ИТ, часто задействуют ServiceNow или BMC Remedy для управления тикетами и SharePoint для обмена знаниями.
• SOCи преимущественно мониторят ИТ-инфраструктуру и только 10% из них берут на контроль еще и АСУ ТП и Интернет вещей. 
• Для большинства SOCов остается проблемой наличие актуальной информации по активам, которые требуют мониторинга. Это связано с тем, что даже в зрелых ИТ-организациях CMDB обладает точной информации хорошо если на 80%. Часто именно SOC, которые предоставляют услуги сканирования и мониторинга учетных записей, сообщают в ИТ знания, которых у ИТ не было даже при наличии CMDB. Еще большую проблему в понимании активов представляет собой использование IaaS/PaaS/SaaS.
• В случае наличия в организации NOC, в большинстве случаев он никак не связан с SOC, и их усилия объединяются только в условиях экстренных ситуаций.
• Авторы отчета отмечают, что ответа на вопрос "Сколько достаточно сотрудников в SOC?" нет. Все зависит от множества факторов. Треть всех опрошенных имеют от 2 до 5 сотрудников в SOC (а всего опросили 355 SOCа по всему миру). Еще треть имеет от 6 до 25 сотрудников. Интересно, что 6 SOCов из 355 (в том числе и Cisco) имеют от 101 до 1000 аналитиков в своем составе, а 3 - более 1000 аналитиков. Хотелось бы знать имена этих "героев". Если же попробовать увязать число аналитиков SOC с размером организации, то картинка получается следующая:
• При численности компании менее 10000 человек в SOC обычно от 2 до 5 аналитиков.
• При численности от 10 до 15 тысяч человек SOC насчитывает обычно от 6 до 10 человек. 
• В организациях от 15 до 100 тысяч сотрудников в SOC обычно работает от 11 до 25 человек.
• В монстрах от 100 тысяч сотрудников SOC насчитывает от 26 до 100 аналитиков.
• Получается, что среднее число айтишников от общей численности компании составляет 3% и еще 3% от службы ИТ составляет ИБ.
• Большинство SOCов построено по централизованной архитектуре, что немудрено. Однако интересным оказалось, что более 10% опрошенных планируют перейти к облачной модели SOC. Еще 10% не имеют вообще никакой четко определенной архитектуры для своего центра мониторинга.
• Интересным, но предсказуемым оказался ответ на вопрос об используемых метриках эффективности SOC. Самыми популярными метриками являются число инцидентов и время от обнаружения инцидента до реагирования и восстановления после него. Их измерять проще всего, опираясь на используемые в SOC инструменты. Бизнес-метрики, о которых я писал в прошлом сентябре, измерять достаточно тяжело и поэтому ими мало кто занимается. Стоимость инцидента как метрику для SOC использует не больше шестой части участвовавших в опросе центров мониторинга, также как и соотношение понесенных и предотвращенных от инцидентов потерь. В практике Cisco у нас был интересный проект по созданию SOC в финансовой организации, где заказчик в качестве одной из основных метрик использовал стоимость выписки по клиенту в Darknet. Ее увеличение говорило об эффективности работы ИБ. Только 11% организаций полностью автоматизировали процесс сбора и представления метрик - остальные используют либо целиком ручной, либо смешанный способ работы с показателями оценки эффективности SOC.
• Список барьеров при построении и эксплуатации SOC более полон, чем у Exabeam, хотя топ этих барьеров почти полностью совпадают:
• Нехватка квалифицированного персонала
• Нехватка автоматизации и оркестрации
• Отсутствие интеграции между инструментами SOC
• Нехватка поддержки руководства
• Нехватка процессов или playbook
• Нехватка видимости на 360 градусов в рамках всего предприятия
• Нехватка корреляции между всеми сигналами тревоги
• Отсутствие кооперации между ИБ, реагированием на инциденты и аналитиками
• Нехватка контекста к событиям безопасности
• Требования регуляторики.

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

Обзор отчета Exabeam по состоянию Security Operations Center

Попался мне тут в руки отчет Exabeam с различной статистикой и обзором происходящего в области Security Operations Center в 2018 году (80% участников опроса имеют опыт работы в SOCах от 6 лет, а длительность работы 90% опрошенных SOC составляет более 3-х лет). Все перечислять не буду, но несколько интересных моментов оттуда я все-таки вытащу:

• Почти половина SOCов продолжает аутсорсить функции Threat Intelligence (ежегодный рост 17%) и анализ вредоносного кода (ежегодный рост 15%), а вот аутсорсинг функции мониторинга (одной из основных для SOC) наоборот снижается (на 10% по сравнению с прошлым годом). Вспоминая недавнюю заметку, становится понятно, почему многие организации (если уж они доросли до идеи SOC) предпочитают все-таки строить свой центр мониторинга, отдавая вовне только сложные сервисы. Также возрастает число кейсов (на 6%), в которых на аутсорсинг отдается внеурочная работа (ночные часы и выходные). Сократилось до нуля число организаций, которые целиком отдавали функцию SOC на аутсорсинг. 
• Менее эффективные SOC имеют больше проблем с нехваткой персонала, чем высоко эффективные центры мониторинга. Трети SOC не хватает 6-10 человек для выполнения своих функций. Интересно, что в России многие службы ИБ насчитывают меньше людей, чем это число.
• Одним из мотивирующих факторов для аналитиков SOC продолжать работать в SOC являются вызовы, с которыми приходится сталкиваться в работе. Иными словами, в центрах, которые занимаются "ерундой" (мало заказчиков при аутсорсинге, мониторинг только периметра и небольшое количество инцидентов), аналитики должно не удерживаются, что приводит к снижению эффективности SOC (я об этом уже писал год назад). И это обычно не находится на поверхности, если речь идет об аутсорсинговом SOC. На желание покинуть SOC активно влияют плохой график работы (о том, что с этим делать, я говорил на прошлом SOC Forum), возможность фриланса (врядли актуально в России), а также отсутствие возможностей для внутреннего роста.
• Возрастает роль так называемых soft skills для аналитиков SOC. Особенно важны становятся социальные навыки, умение коммуницировать и умение работать в команде.
• Из технических навыков возрастает роль threat hunting и поиска утечек информации. А вот важность навыков работы с МСЭ, форензики и анализа вредоносного кода снизилась.
• Общая эффективность SOC за год не изменилась, а вот возможности по автоматизации существенно упали (на 14%).
• Три основных проблемы, возникающие у аналитиков SOC, - время, затрачиваемое на отчетность и документацию, ложные срабатывания и усталость от угроз (а тут недалеко и до психологической слепоты). А в целом у SOC проблемы следующие (в порядке приоритета) - успевать реагировать на все события ИБ, координация между ИБ и ИТ, слабая интеграция различными инструментов ИБ, необновленное оборудование. Тут вроде ничего нового
• В рамках технологического стека у SOCов 4 приоритета - анализ больших данных, EDR (endpoint detection & response), мониторинг сети (NTA) и облаков (но не CASB), а также управление учетными записями. Около 40% SOC используют их в своей работе. Возрастает интерес к машинному обучению, которое может помочь в деятельности SOC, но пока только в крупных центрах мониторинга. 
• Треть высокоэффективных SOCов проводят тренинги персонала на ежемесячной основе, еще столько же - на ежеквартальной, а пятая часть - на еженедельной основе. Это очень необычно для многих российских SOCов (да и вообще служб ИБ), которые не всегда выполняют требования даже пятилетних циклов повышения квалификации для своих сотрудников. Но не нужно думать, что речь всегда идет только о внешних курсах обучения или повышения квалификации. Нередко SOCи проводят внутренние тренинги или онлайн-курсы. Интересно, что высокоэффективные SOC отдают предпочтение внутреннему обучению, в отличие от низкоэффективных, ориентированных на внешнее обучение.
• Интересно отличие в части используемых метрик для больших (более 200 человек) или малых (до 24 человек) SOCов. Последние чаще всего используют время простоя ИТ- или бизнес-сервисов, а первые - число эскалированных инцидентов, время простоя ИТ-сервисов и время от обнаружения инцидента до реагирования и восстановления после него. При этом существуют отличия между тем, какие метрики предпочитают руководители ИТ или ИБ и аналитики SOC. Первым интересно число тикетов по инцидентам, а вторым - время простоя. 
• Только 5% SOCов утверждают, что видят все, что им необходимо. К основным причинам, которые мешают SOCам видеть все, относят - legacy-приложения, которые не отдают события в SIEM, нехватка взаимодействия с владельцами сервисов/приложений, которые должны отдавать события безопасности, нехватка бюджета, а также нестандартизованные технологии (например, в процессе слияний и поглощений или неиспользующие стандарты).
• В тройку основных направлений инвестиций для улучшения SOC входят - новые технологии, персонал и автоматизация.