Как-то с месяц назад меня пригласил к себе один мой старый знакомый, директор по ИБ в одной достаточно крупной компании, с целью, по его словам, «удивить меня». Отмечу, что ранее мы с ним обсуждали вызовы, с которыми столкнулись многие компании в области киберугроз и проблемы построения SOC (Security Operation Center).
Так начинается моя история о построении SOC в компании.
С присущей моменту церемониальностью, директор по ИБ сопроводил меня в опенспейс их Департамента ИТ. И там мне продемонстрировали груду коробок с дорогим «железом», а также распечатку спецификации. Она указывала на покупку лицензий одного всеми известного вендора, входящего в Quadrant for SIEM. Неподдельная радость на его лице говорила о том, что озвученные проблемы из прошлого разговора решились в одночасье. А позже он рассказал мне, что в дополнение к данному «сокровищу» были согласованы деньги на внедрение данной системы, и запланирован наем трех специалистов в штат под данную активность. При этом он сделал особый акцент на «трех специалистах», как бы давая понять, что глубоко проработал вопрос и всё просчитал. Расчет был действительно относительно здравым, но к сожалению, не проверенным эмпирически.
Мы сели и обсудили как структуру проекта построения SOC, так и предложенную им экономическую модель. Попытались оценить выделенные ставки, роли и компетенции, необходимые для выхода на необходимый уровень сервиса.
Изначально, задумка была в том, чтобы поддержку работоспособности «железа» делегировать Департаменту ИТ, отправив их инженеров на специализированные курсы вендора. Далее первую ставку задействовать под инженера-прикладника SIEM. Ожидалось, что данный товарищ сможет после обучения подключать источники событий, а ещё «желательно писать коннекторы, если потребуется» (прямая цитата). Также, в остальное время, участвовать в разборе простых инцидентов. Вторая и третья ставки планировались под экспертов для разборки инцидентов, формировании новых правил корреляции, и развития направления в целом. Также учитывался тот факт, что инцидентов может быть много, а в моменте какой-то из экспертов может заболеть или уйти в отпуск.
На вопрос: «Какой был прогноз: по количеству источников, инцидентов, сложности событий и ожидаемым срокам реакции?», был получен очень сумбурный ответ, а дальше молчание и в заключении, с грустью в голосе: «Потом что-нибудь придумаем!..».
Данный кейс можно назвать вполне типичным для тех компаний, которые по каким-то причинам осознали необходимость внедрения SOC, но не смогли комплексно оценить «масштабы бедствия».
Одной из предпосылок внедрения SOC является достигнутая определенного уровня зрелость компании. Этот уровень позволил ранее закрыть, согласно пирамиде потребностей, базовые вещи и осознать, что теперь для целостной картины не хватает одного важного компонента. Действительно, после того как компания навела порядок в инфраструктуре (архитектура сети, сегментация, домены, процедуры обновления и прочие полезные штуки), а также внедрила необходимый и достаточный набор средств защиты информации (эшелоны защиты, endpoint и пр.), то она невольно задается вопросом: «Как мне всё моё хозяйство видеть и как оценивать то, что я увижу?».
На тот момент в компании предположительно уже существуют выстроенные процессы. Многие из них построенные в лучших традициях ITIL. Support-подразделение ИТ (в некоторых случаях и ИБ) разделено на линии поддержки, и возможно даже есть смены с режимом работы 24*7. Однако стоит отметить, что такие компании встречаются редко, и на моей памяти только 3 из 10, с численностью более 1 000 рабочих станций, могут похвастаться всем этим перечнем достижений.
Все же, если как пример, взять эти 30% счастливчиков, то перед ними стоит задача реализовать интеграционный проект, который должен выродиться в очень важный и критичный сервис. В рамках проекта, описывая жирными мазками, надо:
Казалось бы, всё просто, детализируй каждый пункт, нарисуй план и исполни в намеченный срок. Но дьявол в деталях.
Теперь по порядку.
Технологии SOC – это те инструменты, которые использует сервис для автоматизации сбора информации, корреляции и первичной аналитики. Безусловно, инструментарий определяется имеющимися возможностями и функционалом.
Эксперты SOC – участники команды, с компетенциями по направлениям:
Процессы SOC – это совокупность организационных и технических процедур, которые охватывают 4 направления:
Все составляющие направлены на обнаружение и предотвращение киберугроз.
При этом, самым главным требованием к этим процессам является то, что они должны быть бесшовно внедрены в текущие бизнес-процессы организации. Другими словами, процессы SOC не могут стоять отдельно «особняком» и должны быть, во-первых, филигранно выстроены, а, во-вторых, эффективно выполнять свою задачу – приносить ожидаемую ценность. Также отметим, что под «филигранностью» критичного сервиса понимается абсолютная четкость и согласованность в действиях сотрудников смежных подразделений, при которой не допускается простой и нарушение заданных параметров SLA даже в случае форс-мажора. Не говоря уж о популярных: «сотрудник был на обеде» или «не смогли дозвониться». Результат должен быть четким и в заданный срок. По этой причине, модель работы SOC похожа на военную службу, а принятые регламенты и инструкции — на безоговорочно исполняемый устав.
Парадоксально, но многие уверены, что главной компонентой SOC является инструментарий. В этом случае было бы уместным привести следующий пример. Представляете, вы идете, не дай бог, на операцию. Новость не из радостных, и вас в клинике начинают подбадривают словами о том, что операцию будет делать какой-то хирург, но у него потрясающий скальпель одного из самых дорогих производителей. Причем про «чудо-скальпель» вам скажут несколько раз, а может даже покажут сертификат, подтверждающий его остроту и чистоту металла. Предполагаю, что вас этот аргумент не особо успокоит и вы захотите навести справки о докторе, а также его опыте проведения похожих операций.
Безусловно, выбор SIEM-системы крайне важен и ее функционал должен четко отражать запросы покупателя. Однако всегда нужно помнить тот факт, что SIEM – это только автоматизация, для настройки которой нужны глубокие компетенции и вполне четкая логика работы.
Из приведенного выше перечня необходимых компетенций можно понять, что специалисты SOC это универсальные и высококвалифицированные сотрудники, которые должны находиться на стыке глубоких технических знаний, а также иметь опыт аналитика. К тому же, направление SOC достаточно молодое для РФ и СНГ, а это означает, что в данной предметной области мало экспертов. Встретить на рынке грамотных и «свободных» специалистов крайне сложно. В первую очередь такие специалисты заинтересованы работать, занимаясь новыми и интересными кейсами, которые позволяют развиваться. Нужен поток. По этой причине, они часто «оседают» в крупных сервис-провайдерах и осуществляют ротацию только между аналогичными структурами.
Стоит отметить и уровень зарплат данных специалистов. Ранее коллеги неоднократно приводили аналитику . Информация вполне актуальна и по сей день, за исключением только уровня зарплат – они стали выше, и по рынку в среднем на 15-20%. Это значит, что компания, изъявившая взять в штат экспертов должна выложить вполне серьезные деньги. Насколько эти деньги релевантны приносимой пользе, при условии, что мало какая компания (исключение – «Сервис-провайдер») может утилизировать время такого эксперта хотя бы на 70%? Даже, если такого эксперта схантили высоким окладом, вероятность того, что он подыщет себе более интересную работу – высока. К тому же, есть статистика, что участники команды такого рода проекта-сервиса за 3-7 лет полностью обновляются. Это реальность и с ней надо считаться.
Итак, компания купила замечательный инструментарий, функциональную и эффективную SIEM-систему, взяла в штат талантливого и опытного эксперта по SOC, который смог создать дружную и согласованную команду ответственных специалистов. Далее эта команда должна взять систему на сопровождение, разработать необходимые процедуры и регламенты, внедрить их и начать по ним работать. Стоит отметить, что даже после хорошего консалтинга со стороны интегратора, который помогал стоить SOC (внедрял систему, делал аудит процессов, создавал базовые правила и писал необходимые инструкции), на плечи команды SOC ложится огромный пласт работ по оптимизации созданного под реалии компании центра реагирования. Причесывание процессов и схем работы следует в режиме «case by case».
Если же консалтинга не было, и команда должна построить SOC самостоятельно, то история становится ещё более интересной и затратной. Это как студента-выпускника (пусть хоть с красным дипломом) в первые дни работы на производстве ставить на самый ответственный участок, и надеяться, что он «как-нибудь сориентируется».
Отсюда следует, что чтобы доверить построение SOC создаваемой команде, нужно быть готовым к двум сценариям:
Из двух сценариев более бюджетным, вероятнее, будет первый вариант по причине гарантии результата и сроков выхода на целевую работу сервиса. Более того, в первом варианте спонсор проекта-сервиса уже изначально понимает количество необходимых сотрудников и состав необходимых ролей (количество линий поддержки, в т.ч. режим работы 24*7 или 8*5; количество аналитиков с функционалом; support по SIEM и компонентам и пр.). При втором – обычно спонсор рассуждает следующими категориями: «У нас есть 5 универсальных единиц работы, каждый эксперт может взять 2 единицы работы в моменте, значит берем двух экспертов и одного студента». Как бы это не казалось смешным, но практика показывает, что в суете потока задач, некоторые руководители машинально принимают такие решения. И при этом уверены в результате, под девизом: «были бы хорошие сотрудники, а как их задействовать и нагрузить потом придумаем».
Сейчас Интернет пестрит последними трендами: цифровая трансформация (digital-transformation), компании полностью уходят в «облака», непрофильные процессы выносят на аутсорсинг. Крупные компании начинают предлагать платформы, с помощью которых можно набрать необходимое количество сервисов для поддержания и развития бизнеса любого размера. Аутсорсинг по бухгалтерии, юридическим услугам, call-центрам, IT «под ключ»: это только начало глобальных изменений. Причем виды сервисов могут быть абсолютно любыми. Те, которые ещё вчера казались бы невероятными и оригинальными, как например «аутсорсинг печати», сегодня пользуются огромным спросом. Причем тренд развития сервисно-ориентированной модели мы можем увидеть по Западному рынку, который традиционно опережает РФ и СНГ. Он огромный и покрывает все отрасли.
SOC as a Service (SOCaaS) не является исключением. На рынке достаточно игроков, провайдеров сервисов информационной безопасности (Managed Security Service Provider, MSSP), которые предлагают клиентам не «изобретать колесо», а просто воспользоваться экспертизой и опытом в этой области. Эксперты именно здесь, на «потоке», набивают руку и получают огромный опыт, который позволяет им составлять четкие и эффективные процессы. Они собирают все грабли, чтобы проанализировать все возможные сценарии и предложить опции, релевантные потребностям клиентов. Клиенту не надо ничего придумывать, он просто примеряет на себя предлагаемые опции и выбирает нужные.
Что самое «вкусное» в этой истории, так это то, что:
Для моего товарища есть два варианта для успешного выхода из данной ситуации:
При любом раскладе, оба варианта соразмерны со стоимостью потраченных средств на лицензии SIEM и получаются в разы дороже управляемого сервиса с аналогичными параметрами. Это факт! Вот почему сейчас это направление так активно развивается и пользуется большим спросом среди заинтересованных компаний.
Однако надо признать, что даже самый лучший сервис не является универсальным средством решения всех проблем и болей клиента. И всё как обычно остается на откуп конкретной задачи, размеру кошелька и педантичности заказчика SOC.
Денис Гущин, заместитель генерального директора Infosecurity.
Так начинается моя история о построении SOC в компании.
С присущей моменту церемониальностью, директор по ИБ сопроводил меня в опенспейс их Департамента ИТ. И там мне продемонстрировали груду коробок с дорогим «железом», а также распечатку спецификации. Она указывала на покупку лицензий одного всеми известного вендора, входящего в Quadrant for SIEM. Неподдельная радость на его лице говорила о том, что озвученные проблемы из прошлого разговора решились в одночасье. А позже он рассказал мне, что в дополнение к данному «сокровищу» были согласованы деньги на внедрение данной системы, и запланирован наем трех специалистов в штат под данную активность. При этом он сделал особый акцент на «трех специалистах», как бы давая понять, что глубоко проработал вопрос и всё просчитал. Расчет был действительно относительно здравым, но к сожалению, не проверенным эмпирически.
Мы сели и обсудили как структуру проекта построения SOC, так и предложенную им экономическую модель. Попытались оценить выделенные ставки, роли и компетенции, необходимые для выхода на необходимый уровень сервиса.
Изначально, задумка была в том, чтобы поддержку работоспособности «железа» делегировать Департаменту ИТ, отправив их инженеров на специализированные курсы вендора. Далее первую ставку задействовать под инженера-прикладника SIEM. Ожидалось, что данный товарищ сможет после обучения подключать источники событий, а ещё «желательно писать коннекторы, если потребуется» (прямая цитата). Также, в остальное время, участвовать в разборе простых инцидентов. Вторая и третья ставки планировались под экспертов для разборки инцидентов, формировании новых правил корреляции, и развития направления в целом. Также учитывался тот факт, что инцидентов может быть много, а в моменте какой-то из экспертов может заболеть или уйти в отпуск.
На вопрос: «Какой был прогноз: по количеству источников, инцидентов, сложности событий и ожидаемым срокам реакции?», был получен очень сумбурный ответ, а дальше молчание и в заключении, с грустью в голосе: «Потом что-нибудь придумаем!..».
Данный кейс можно назвать вполне типичным для тех компаний, которые по каким-то причинам осознали необходимость внедрения SOC, но не смогли комплексно оценить «масштабы бедствия».
Мы «созрели», нам нужен SOC
Одной из предпосылок внедрения SOC является достигнутая определенного уровня зрелость компании. Этот уровень позволил ранее закрыть, согласно пирамиде потребностей, базовые вещи и осознать, что теперь для целостной картины не хватает одного важного компонента. Действительно, после того как компания навела порядок в инфраструктуре (архитектура сети, сегментация, домены, процедуры обновления и прочие полезные штуки), а также внедрила необходимый и достаточный набор средств защиты информации (эшелоны защиты, endpoint и пр.), то она невольно задается вопросом: «Как мне всё моё хозяйство видеть и как оценивать то, что я увижу?».
На тот момент в компании предположительно уже существуют выстроенные процессы. Многие из них построенные в лучших традициях ITIL. Support-подразделение ИТ (в некоторых случаях и ИБ) разделено на линии поддержки, и возможно даже есть смены с режимом работы 24*7. Однако стоит отметить, что такие компании встречаются редко, и на моей памяти только 3 из 10, с численностью более 1 000 рабочих станций, могут похвастаться всем этим перечнем достижений.
Все же, если как пример, взять эти 30% счастливчиков, то перед ними стоит задача реализовать интеграционный проект, который должен выродиться в очень важный и критичный сервис. В рамках проекта, описывая жирными мазками, надо:
- Внедрить и настроить SIEM-систему (интеграция с service desk или аналогом; настройка и подключение источников событий; кастомизация и применение базовых правил корреляции и пр. и пр.).
- Нанять и обучить персонал (специализированные курсы вендора по siem-системе, проведение расследований и пр.).
- Задокументировать и внедрить регламенты / инструкции реагирования (в т.ч. альбомы инцидентов, провести ранжирование по критичности/сложности и ещё огромный набор документов, соразмерный, в распечатанном виде, с результатами по гос. контрактам).
- Определить зоны ответственности между подразделениями, прописать четко SLA и запустить сервис.
- Откупорить и продегустировать бутылочку шипучего, когда поступят первые инциденты и будут четко обработаны. Данный пункт опциональный и зависит исключительно от внутренней культуры компании. Достаточным будет проверка, что сервис работает согласно заданным SLA.
Казалось бы, всё просто, детализируй каждый пункт, нарисуй план и исполни в намеченный срок. Но дьявол в деталях.
SOC – это используемые технологии, эксперты и выстроенные процессы.
Теперь по порядку.
Технологии SOC – это те инструменты, которые использует сервис для автоматизации сбора информации, корреляции и первичной аналитики. Безусловно, инструментарий определяется имеющимися возможностями и функционалом.
Эксперты SOC – участники команды, с компетенциями по направлениям:
- администрирование ОС, СУБД, AD и сетевых компонент;
- администрирование прикладных систем ИБ;
- администрирование прикладных систем ИТ;
- аналитика (мониторинг и 2я линия для SOC);
- аналитика с релевантным опытом и экспертизой (3я линия для SOC: от 3х лет работы в профильных компаниях, а также участие в расследованиях инцидентов).
Процессы SOC – это совокупность организационных и технических процедур, которые охватывают 4 направления:
- Поддержка инфраструктуры SOC (infrastructure support);
- Мониторинг событий безопасности (monitoring);
- Расследование инцидентов (incident investigetion / responce);
- Развитие (service development).
Все составляющие направлены на обнаружение и предотвращение киберугроз.
При этом, самым главным требованием к этим процессам является то, что они должны быть бесшовно внедрены в текущие бизнес-процессы организации. Другими словами, процессы SOC не могут стоять отдельно «особняком» и должны быть, во-первых, филигранно выстроены, а, во-вторых, эффективно выполнять свою задачу – приносить ожидаемую ценность. Также отметим, что под «филигранностью» критичного сервиса понимается абсолютная четкость и согласованность в действиях сотрудников смежных подразделений, при которой не допускается простой и нарушение заданных параметров SLA даже в случае форс-мажора. Не говоря уж о популярных: «сотрудник был на обеде» или «не смогли дозвониться». Результат должен быть четким и в заданный срок. По этой причине, модель работы SOC похожа на военную службу, а принятые регламенты и инструкции — на безоговорочно исполняемый устав.
Парадоксально, но многие уверены, что главной компонентой SOC является инструментарий. В этом случае было бы уместным привести следующий пример. Представляете, вы идете, не дай бог, на операцию. Новость не из радостных, и вас в клинике начинают подбадривают словами о том, что операцию будет делать какой-то хирург, но у него потрясающий скальпель одного из самых дорогих производителей. Причем про «чудо-скальпель» вам скажут несколько раз, а может даже покажут сертификат, подтверждающий его остроту и чистоту металла. Предполагаю, что вас этот аргумент не особо успокоит и вы захотите навести справки о докторе, а также его опыте проведения похожих операций.
Безусловно, выбор SIEM-системы крайне важен и ее функционал должен четко отражать запросы покупателя. Однако всегда нужно помнить тот факт, что SIEM – это только автоматизация, для настройки которой нужны глубокие компетенции и вполне четкая логика работы.
Эксперты и процессы являются краеугольным камнем при создании SOC
Из приведенного выше перечня необходимых компетенций можно понять, что специалисты SOC это универсальные и высококвалифицированные сотрудники, которые должны находиться на стыке глубоких технических знаний, а также иметь опыт аналитика. К тому же, направление SOC достаточно молодое для РФ и СНГ, а это означает, что в данной предметной области мало экспертов. Встретить на рынке грамотных и «свободных» специалистов крайне сложно. В первую очередь такие специалисты заинтересованы работать, занимаясь новыми и интересными кейсами, которые позволяют развиваться. Нужен поток. По этой причине, они часто «оседают» в крупных сервис-провайдерах и осуществляют ротацию только между аналогичными структурами.
Стоит отметить и уровень зарплат данных специалистов. Ранее коллеги неоднократно приводили аналитику . Информация вполне актуальна и по сей день, за исключением только уровня зарплат – они стали выше, и по рынку в среднем на 15-20%. Это значит, что компания, изъявившая взять в штат экспертов должна выложить вполне серьезные деньги. Насколько эти деньги релевантны приносимой пользе, при условии, что мало какая компания (исключение – «Сервис-провайдер») может утилизировать время такого эксперта хотя бы на 70%? Даже, если такого эксперта схантили высоким окладом, вероятность того, что он подыщет себе более интересную работу – высока. К тому же, есть статистика, что участники команды такого рода проекта-сервиса за 3-7 лет полностью обновляются. Это реальность и с ней надо считаться.
Итак, компания купила замечательный инструментарий, функциональную и эффективную SIEM-систему, взяла в штат талантливого и опытного эксперта по SOC, который смог создать дружную и согласованную команду ответственных специалистов. Далее эта команда должна взять систему на сопровождение, разработать необходимые процедуры и регламенты, внедрить их и начать по ним работать. Стоит отметить, что даже после хорошего консалтинга со стороны интегратора, который помогал стоить SOC (внедрял систему, делал аудит процессов, создавал базовые правила и писал необходимые инструкции), на плечи команды SOC ложится огромный пласт работ по оптимизации созданного под реалии компании центра реагирования. Причесывание процессов и схем работы следует в режиме «case by case».
Если же консалтинга не было, и команда должна построить SOC самостоятельно, то история становится ещё более интересной и затратной. Это как студента-выпускника (пусть хоть с красным дипломом) в первые дни работы на производстве ставить на самый ответственный участок, и надеяться, что он «как-нибудь сориентируется».
Отсюда следует, что чтобы доверить построение SOC создаваемой команде, нужно быть готовым к двум сценариям:
- Набрать команду из специалистов, которые уже создавали аналогичный сервис (либо данным составом, либо каждый участник по отдельности согласно своей роли).
- Набрать экспертов из похожих областей с релевантными знаниями и «залить» деньгами путь из ошибочных решений, недоработок и несогласованных действий.
Из двух сценариев более бюджетным, вероятнее, будет первый вариант по причине гарантии результата и сроков выхода на целевую работу сервиса. Более того, в первом варианте спонсор проекта-сервиса уже изначально понимает количество необходимых сотрудников и состав необходимых ролей (количество линий поддержки, в т.ч. режим работы 24*7 или 8*5; количество аналитиков с функционалом; support по SIEM и компонентам и пр.). При втором – обычно спонсор рассуждает следующими категориями: «У нас есть 5 универсальных единиц работы, каждый эксперт может взять 2 единицы работы в моменте, значит берем двух экспертов и одного студента». Как бы это не казалось смешным, но практика показывает, что в суете потока задач, некоторые руководители машинально принимают такие решения. И при этом уверены в результате, под девизом: «были бы хорошие сотрудники, а как их задействовать и нагрузить потом придумаем».
А может лучше SOC as a Service?
Сейчас Интернет пестрит последними трендами: цифровая трансформация (digital-transformation), компании полностью уходят в «облака», непрофильные процессы выносят на аутсорсинг. Крупные компании начинают предлагать платформы, с помощью которых можно набрать необходимое количество сервисов для поддержания и развития бизнеса любого размера. Аутсорсинг по бухгалтерии, юридическим услугам, call-центрам, IT «под ключ»: это только начало глобальных изменений. Причем виды сервисов могут быть абсолютно любыми. Те, которые ещё вчера казались бы невероятными и оригинальными, как например «аутсорсинг печати», сегодня пользуются огромным спросом. Причем тренд развития сервисно-ориентированной модели мы можем увидеть по Западному рынку, который традиционно опережает РФ и СНГ. Он огромный и покрывает все отрасли.
SOC as a Service (SOCaaS) не является исключением. На рынке достаточно игроков, провайдеров сервисов информационной безопасности (Managed Security Service Provider, MSSP), которые предлагают клиентам не «изобретать колесо», а просто воспользоваться экспертизой и опытом в этой области. Эксперты именно здесь, на «потоке», набивают руку и получают огромный опыт, который позволяет им составлять четкие и эффективные процессы. Они собирают все грабли, чтобы проанализировать все возможные сценарии и предложить опции, релевантные потребностям клиентов. Клиенту не надо ничего придумывать, он просто примеряет на себя предлагаемые опции и выбирает нужные.
Что самое «вкусное» в этой истории, так это то, что:
- за вполне приемлемые деньги, клиент получает весь перечень дорогих экспертов в необходимом ему объеме;
- сервис качественно спроектирован, вышколен и апробирован на других компаниях;
- сервисная компания деньгами отвечает за выполнение SLA и «человеческий фактор»;
- клиент получает сервис «под ключ». Это значит, что клиенту не нужно генерировать предложения по развитию сервиса, сервис провайдер придет с ними сам. И конечно же никаких беспокойств о мотивации команды SOC или «текучки» специалистов. Об этом позаботится уже сам выбранный партнер.
А что в итоге?
Для моего товарища есть два варианта для успешного выхода из данной ситуации:
- Получить дополнительный бюджет на грамотных экспертов, которые ранее уже строили SOC и расширить штат ещё минимум на 4 человек (а при режиме 24*7 – на 7 специалистов), выполнить после этого амбициозный внутренний проект.
- Получить ещё больший бюджет для построения SOC «под ключ», где исполнителем выступит квалифицированный и опытный сервис-провайдер. Это целый роман стоимостью в десятки миллионов рублей (capex), но с гарантированным результатом. Opex потом тоже будет соизмерим с п.1, однако требуемый уровень сервиса будет получен значительно быстрее.
При любом раскладе, оба варианта соразмерны со стоимостью потраченных средств на лицензии SIEM и получаются в разы дороже управляемого сервиса с аналогичными параметрами. Это факт! Вот почему сейчас это направление так активно развивается и пользуется большим спросом среди заинтересованных компаний.
Однако надо признать, что даже самый лучший сервис не является универсальным средством решения всех проблем и болей клиента. И всё как обычно остается на откуп конкретной задачи, размеру кошелька и педантичности заказчика SOC.
Денис Гущин, заместитель генерального директора Infosecurity.
