Вы готовы к аутсорсинговому SOCу?

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

1. Определитесь сначала, что для вас SOC и какие сервисы вы от него ждете? Готов ли аутсорсер вам их предоставить? Это один из моих любимых вопросов, который возникает даже в случае проектирования SOC, а не только при его аутсорсинге. Дело в том, что у всех совершенно разное представление о том, что входит в это понятие и какие сервисы должны предоставляться SOCом. Не определившись на берегу с тем, что вы готовы отдать сейчас и в перспективе, дальше работать будет сложно и затратно. Например, если вам аутсорсер предлагает мониторинг ваших средств защиты, но не имеет в своем портфолио услуги по реагированию и расследованию, то как вы закроете эти свои потребности? Приглашать еще одного аутсорсера (а то и двух)? 
2. У вас есть четкое понимание термина «инцидент»? Когда ФинЦЕРТ или НКЦКИ требуют присылать данные по каждому спам-сообщению или по каждой уязвимости, это говорит, что они сами не применяли свои же требования к себе. И то, что можно оперативно отработать, когда вы проектируете SOC для себя, не так просто поменять в рамках договорных условий. Если вы неправильно определили понятие инцидента, то вам будут слать или слишком много событий и вы утонете в них, или слишком мало и вы начнете что-то пропускать.
3. Аутсорсинг подразумевает, что между вами и вашим аутсорсером находится пропасть Интернет. А он надежен? У вас нормальные каналы (с резервированием?) до всех ваших площадок, которые вы отдаете на аутсорсинг? А у аутсорсера они нормальные (особенно если он с целью экономии открыл свои центры не в Москве)? 
4. Вы готовы отдать аутсорсинговому SOC мониторинг внутренней инфраструктуры? С периметром все более или менее понятно — это делают многие. А вот как мониторить Netflow в вашей инфраструктуре? А EDR (если он есть) на хостах? А UEBA тоже отдается во внешний SOC? Если вы разделяете мониторинг периметровый и внутренний, то вам придется строить два SOCа, а это непростая задача. Не только в части ресурсов, но и в части интеграции данных из разных SOCов. Кстати, ваш аутсорсер имеет опыт мониторинга внутренней инфраструктуры или все его проекты — это мониторинг МСЭ и СОВ?
5. А кто будет реагировать на обнаруженные инциденты? Большое заблуждение считать, что отдав на аутсорсинг мониторинг ИБ, вы можете теперь спать спокойно и снять с себя головную боль, связанную с ИБ. Она у вас только начинается, так как надо будет более четко прописать все процедуры взаимодействия между вами и аутсорсером, разделить зоны ответственности, договориться со своей службой ИТ и т.п. Это один из самых непростых вопросов в аутсорсинге SOC.
6. Как выстроена система управления заявками у аутсорсера? Процесс общения с внешним поставщиком услуг является достаточно формальным, что требует хорошо регламентированной и автоматизированной процедуры, которая позволит оперативно решать многие вопросы. Например, согласование изменений в настройках СОВ и МСЭ или установка патча для обнаруженной уязвимости. Если за реагирование отвечаете именно вы, а не аутсорсер, то этот вопрос очень важен.
7. Какой SLA будет прописан в договоре? 15 минут на реагирование на инциденты хорошо звучат в маркетинговых презентациях, а под какими цифрами в подписываемом договоре готов подписаться аутсорсер? И это 15 минут на реагирование или все-таки для обнаружения, локализации и закрытия инцидента будут разные SLA? А SLA одинаков для всех инцидентов или для инцидентов разного приоритета и соглашение о качестве сервиса будет разным?
8. С какими use case чаще всего имел дело аутсорсер? Они пересекаются с вами? Не верьте, когда вам говорят, что SIEM/SOC может обнаруживать абсолютно все. Это некоторое лукавство. Есть наборы предопределенных сценариев, которые заложены в SIEM/UEBA/NTA аутсорсера, под которые у него написаны playbook, и с которыми он постоянно имеет дело. Что-то нетипичное для него, но типичное для вас, может вызвать сложности в реализации.
9. Портал для клиента сегодня предоставляют многие аутсорсинговые SOCи (но вы, конечно, уточните). Поинтересуйтесь, что там будет отображаться? Какие dashboard есть у аутсорсера? Насколько они будут полезны вам? И, кстати, реализован ли ролевой доступ к порталу SOC?
10. Какой доступ имеет аутсорсер к вашей инфраструктуре? Если аутсорсер получил право настраивать ваши периметровые средства защиты, то как будет делиться ответственность за их работоспособность между ним и вашей ИТ-службой? Насколько критичные и чувствительные данные сможет видеть аутсорсер, если вы предоставите ему доступ к внутренней инфраструктуре? Какие настройки потребуется сделать у вас на периметре, чтобы пустить аутсорсера внутрь вашей инфраструктуры? И, кстати, как вы убедитесь, что через канал с аутсорсером к вам не залезут плохие парни? Совсем недавно прокатилась волна взломов провайдеров услуг, через которых затем уже ломали самих клиентов.
11. Ударим по больному. Какова ответственность аутсорсера за пропуск инцидента? Ее может не быть вовсе, но вы же должны к этому быть готовы. А если она есть, то какая? Финансовая? Или продление срока контракта на время простоя от пропущеннога инцидента? Или скидка на следующий год? Тут возникает и обратный вопрос. А какова ваша ответственность за неустраненные косяки в инфраструктуре, благодаря которым инцидент стал возможным? Что делать, если аутсорсер вам сообщил о необходимости накатить нужный патч, а вы проигнорировали его уведомление и это стало причиной взлома? Любой контракт — это документ, устанавливающий права и обязанности для обеих сторон, а не только для той, кому вы платите деньги. Вы готовы к тому, чтобы отвечать за что-то по договору, а не только требовать? 
12. Мир безопасности постоянно меняется — новые угрозы, новые требования регулятора, новые технологии (это если рассматривать только внешние драйверы). У вашего аутсорсера запланированы ежеквартальные встречи с вами для обсуждения новых угроз и включения их в use case? Кто является инициатором таких изменений? По уму, это предлагать должен вам аутсорсер — он же ваш доверенный советник по вопросам ИБ.
13. Вроде как очевидный факт, что угрозы актуальны только если у вас есть уязвимости в вашей инфраструктуре. Кто отвечает за их устранение? Ваша ИТ-служба вовлечена в процесс аутсорсинга ИБ? Может случиться так, что процедура управления уязвимостями у ваших айтишников отличается от подходов, принятых аутсорсером. И это тоже надо обсуждать еще на берегу.
14. Где хранятся логи ваших средств защиты? Многие аутсорсеры на Западе переходят на модель оплаты «storage-based» и это понятно — объемы хранения достаточно велики и кто-то должен компенсировать затраты на построение ЦОДа или аренду вычислительных мощностей для хранения большого объема событий безопасности. Например, в стандарте Банка России по менеджменту инцидентов требуется хранить события безопасности от 3-х до 5 лет (оставим в стороне вопрос, зачем так долго). И тут у вас возникает дилемма. Либо хранить у вас, но тогда как проводить расследования в ретроспективе? Как аутсорсер получит доступ к данным, которые хранятся у вас? Примонтирует ваши диски к его SIEM? А если хранить данные у аутсорсера, то это может вылететь в копеечку.  
15. По договору вам будут присылать кучу отчетов по результатам работ (обычно в PDF). В какой-то момент времени вы настроите правило в вашем почтовом клиенте, чтобы все отчеты складывались в отдельную папку, которую вы… никогда уже не откроете 🙂 Подумайте о том, как вы выстроите процесс ознакомления с отчетами от аутсорсера? Может через портал? Может у него есть вариант с настраиваемыми параметрами для отправки отчетов и их содержимого?
16. Цена аутсорсинга складывается из стоимость контракта + стоимость обработки ложных срабатываний + стоимость обработки инцидентов вашей ИТ/ИБ. Как аутсорсер борется с ложными срабатываниями? 
17. SOC — тема модная и нужная, но и ее не обошла своим вниманием проблема compliance. Как защищаются ваши данные в SOC? Как обеспечивается выполнение GDPR или ФЗ-152 в SOC? А требования по КИИ (там есть свои нюансы)? 
18. Вы не боитесь атрофии вашей службы ИБ, которая становится слишком зависимой от аутсорсера? Аутсорсинг — это не плохо, просто вы должны осознанно прийти к этому решению.

• Для первой линии. 2-я и последующие должны реализовываться вами. В данном сценарии вы всю черновую работу перекладываете на плечи аутсорсера.
• Для ночной работы. Если вы не готовы пока переходить на круглосуточный режим работы, то можно поручить ночные смены аутсорсеру. 
• Для базового мониторинга. Какие-нибудь простые use case вы можете отдать аутсорсеру, оставив себе сложные темы, для расследования которых аутсорсеру просто не хватает знаний о вашей инфраструктуре и процессах. 
• Для ДМЗ. Да, периметр можно отдать в руки аутсорсера, особенно, если он еще по совместительству является и поставщиком услуг Managed Security (MSS), а себе оставить мониторинг внутренней инфраструктуры.
• Для помощи в управлении SIEM. Сегодня появляются облачные или аутсорсинговые SIEM, а по прогнозам Gartner в 2020-м году чуть ли не 90% всех SIEM-вендоров (явно не российских) будут предлагать свои продукты из облака, снижая нагрузку на своих заказчиков.
• Помощь в серьезных инцидентах. Не имея возможности содержать квалифицированные кадры для третьей линии, вы можете эту задачу поручать как раз внешнему аутсорсеру.