В чем заключается основная функция группы реагирования на инциденты cisco csirt
Фокус на реагирование: CSIRT как новый подход к аутсорсингу SOC
Несмотря на то, что рынок услуг аутсорсинга Security Operations Centers на сегодняшний день в большей степени сформирован, многие заказчики предпочитают выстраивать процессы мониторинга и реагирования на инциденты ИБ собственными силами. Почему компании не используют аутсорсинг SOC в полной мере, в чем недостатки существующих типовых коммерческих операционных центров безопасности, и как изменить ситуацию — ответы на эти вопросы в нашей статье.
Введение
К середине 2018 года рынок услуг экспертного аутсорсинга мониторинга и реагирования на инциденты ИБ в большей степени сформировался. Если несколько лет назад значительная часть участников рынка рассуждала о том, имеет ли вообще право на жизнь экспертный аутсорсинг, то сейчас его преимущества не вызывают никаких сомнений, клиенты активно им пользуются и уже можно делать полноценные выводы об этом направлении.
Компания «Инфосистемы Джет» стояла у истоков развития экспертного аутсорсинга в России. В 2012 году наши специалисты хорошо изучили направление, сформировали технологическую базу и вскоре разработали первый коммерческий сервис, в значительной мере давший импульс всему российскому рынку ИБ.
В то же время шестилетний опыт работы в этой сфере позволил нам глубоко исследовать применяемые подходы на практике. Мы взаимодействовали с десятками клиентов, которые уже пользовались услугами аутсорсинга ИБ в той или иной степени или рассматривали такую возможность. Реальная практика подвела нас к пониманию назревшей необходимости в корректировке существующих подходов к экспертному аутсорсингу. На наш взгляд, главным образом в изменениях нуждаются именно процессы реагирования.
Отвечая на запросы рынка, мы создали новую услугу — специализированный центр реагирования на инциденты ИБ Jet CSIRT (Jet Computer Security Incident Team). Данный сервис стал для нас не революцией, не кардинальной сменой парадигмы, а скорее эволюционным шагом развития подхода, разработанного нами же ранее.
Сегодня мы предлагаем подробно рассмотреть проблематику вопроса и расскажем, как именно разработанная нашими экспертами услуга поможет изменить сложившуюся ситуацию в корне.
Три проблемы существующих подходов в аутсорсинге SOC
Сервисы не учитывают потребности рынка
Первая проблема заключается в том, что сервис-провайдеры создают услуги исходя из своих текущих возможностей и ресурсов. Другими словами, они не проводят глобальные исследования рынка и не изучают запросы заказчиков. Причем нередко мы сталкиваемся с отсутствием у таких организаций опыта собственного плотного взаимодействия с клиентами. Подобный подход недопустим, поскольку речь идет о цепочке сложных взаимосвязанных процессов.
А что в результате? Клиенты не получают полностью удовлетворяющие их услуги аутсорсинга процессов мониторинга и реагирования на инциденты ИБ. Статистика SANS за 2017 год показывает, что владельцы информационных систем пока предпочитают поддерживать и развивать процессы самостоятельно и не используют аутсорсинг в полной мере.
Рисунок 1. Процессы ИБ (в среднем по миру), реализуемые клиентами самостоятельно и посредством аутсорсинга (статистика SANS за 2017 г.)
Стоит отметить, что в ряде отраслей аутсорсинг скорее всего так и останется невостребованным в силу их закрытости. Тем не менее широкое распространение сервиса, отвечающего запросам типового заказчика, могло бы существенно изменить картину на рынке.
Добавим, что ситуация усугубляется маркетинговым «бумом» всевозможных направлений, практик и технологий. Стремление поставщиков услуг и решений переиграть конкурентов иногда приводит к комичным ситуациям, когда под одинаковыми названиями предлагаются абсолютно разные продукты либо, наоборот, разные названия подразумевают одно и то же. Яркий пример – всевозможные решения класса Security Intelligence или Anti-APT. Аналогичная картина наблюдается и в аутсорсинге Incident Response, где распространено большое количество схожих названий, за которыми фактически может скрываться любой ИБ-продукт. Для начала разберемся с определениями:
Теперь обратимся к лучшим мировым практикам по управлению инцидентами ИБ. Так, стандарт NIST SP 800-61 Rev. 2 (Computer Security Incident Handling) содержит следующие этапы, процессы и подпроцессы:
Отметим, что схожий подход представлен в стандарте ISO/IEC 27035:2016.
Как же соотносятся популярные аббревиатуры с процессами управления ИБ на практике? Зачастую традиционный коммерческий SOC фокусируется на процессе детектирования, CERT нацелен на глобальную и региональную кибераналитику и иногда на ограничение распространения массовых угроз. Под MSSP часто понимают аутсорсинг функций средств защиты информации. Например, это может быть MSSP WAF — WAF из облака или WAF как услуга.
Лучшие практики FIRST CSIRT Framework и NIST SP 800-61 показывают, что CSIRT широко покрывает большинство процессов Incident Response. Помимо этого, продукт охватывает проектирование систем информационной безопасности, аудит и консалтинг, пентесты и разработку СЗИ. Что важно, CSIRT лучше всего подходит для предоставления услуг по сервисной модели среди рассматриваемых концепций аутсорсинга Incident Response.
Наш опыт взаимодействия с клиентами и результаты исследования уровней зрелости SOC в мире компании Micro Focus демонстрируют, что большинству заказчиков нужна комплексная помощь и поддержка по всем процессам Incident Response, а не только в части мониторинга, предоставления им «SIEM в облаке» или в расследовании инцидентов ИБ. Клиентам требуется помощь в аналитике, реагировании, формировании playbooks по реагированию, оптимизации настроек и эксплуатации СЗИ, периодической проверке уровня защищенности и т.д.
Процессы реагирования — слабое звено Incident Response
Вторая проблема, на наш взгляд, связана с нередким отсутствием понимания сервис-провайдерами сути и глубины процессов Incident Response. Зачастую основной фокус делается на детектировании атак, что находит свое отражение в регламентах коммерческих SOC. Действительно, задача детектирования крайне важна и является одним из самых сложных элементов Incident Response. В то же время, как было показано выше, процесс реагирования на инциденты ИБ представляет собой цепочку взаимосвязанных процессов, а именно: Preparation, Detection, Containment/Eradiation/Recovery, Post-Incident Activity.
Рисунок 2. Этапы Incident Response (NIST 800-61)
Зрелость глобального процесса Incident Response определяется самым слабым звеном. Что это значит? Если представлена слабая система безопасности, недостаточно проработаны процессы, не детализированы регламенты, неграмотно осуществлено разделение труда и отсутствуют узкопрофильные специалисты, то даже самая сильная экспертиза в детектировании не станет панацеей от угроз. При этом на практике, как это ни парадоксально, мы часто наблюдаем случаи, когда в рамках служб SOC основной фокус делается на детектировании и почти полностью игнорируются процессы реагирования. В итоге это приводит к написанию крайне упрощенных регламентов, в которых процесс реагирования изначально имеет размытые зоны ответственности и упрощенную структуру, что, безусловно, снижает эффективность множества процессов Incident Response в целом. Приведем аналогию из жизни: важно не только вовремя правильно диагностировать заболевание, но и оперативно назначить пациенту эффективное квалифицированное лечение.
Кроме того, существуют важнейшие перманентные процессы, такие как Threat Hunting — проактивный поиск угроз, которые не обнаруживаются традиционными средствами детектирования. Важно понимать, что Threat Hunting требует хорошей координации между командами, в том числе с ИТ-специалистами и владельцами активов, а также глубокого погружения в инфраструктуру.
Рисунок 3. Процесс Threat Hunting (подход Carbon Black)
Другими словами, Threat Hunting невозможно выполнить лишь силами команды мониторинга без погружения в инфраструктуру, на чем специализируются команды реагирования и эксплуатации. Можно констатировать, что сегодня полноценный Threat Hunting реализуется в очень малом количестве коммерческих SOC. На практике вместо предоставления клиентам услуги экспертного аутсорсинга SOC и сопутствующей аналитики сервис-провайдеры ограничиваются поверхностным детектированием.
Вот и получается, что без таких процессов как Threat Hunting и выстроенных процессов Incident Response типовой коммерческий SOC представляет собой просто SIEM как сервис (SIEM в облаке). Это достаточно важный момент, ведь многие сервис-провайдеры выстраивают конвейер, минимизируя свое погружение в процессы и инфраструктуру клиента. В итоге через один-два года клиенты выражают недовольство и разочарование, а иногда и вовсе прекращают пользоваться услугами экспертного аутсорсинга, переходя к идее собственного SOC с учетом значительных издержек на его создание.
Трудности взаимодействия всех участников процессов Incident Response
Третья, не менее важная проблема может возникнуть при реализации мониторинга и реагирования в зрелом формате, когда необходимо выстроить эффективное взаимодействие между профильными группами и определить роль каждого участника. Сложность здесь заключается в том, что крайне трудно наладить продуктивную координацию между командами Incident Response, если они представляют разные стороны. С этим мы нередко сталкиваемся даже на CTF-соревнованиях, в которых компания «Инфосистемы Джет» часто принимает участие: команды SOC и команды реагирования находятся в считанных метрах друг от друга и при этом почти всегда испытывают сложности взаимодействия. Что уж говорить о реальных контрактах, где у разных команд могут быть разные KPI, приоритеты, интересы или квалификация. В итоге из-за отсутствия слаженности действий очень сильно страдает не только эффективность процессов, но и драматически увеличивается время их выполнения.
Рисунок 4. Среднее время отработки процессов Incident Response (статистика SANS за 2017 г.)
Мы уверены, что лучшее решение данной проблемы — привлечение сработанных команд и минимизация количества участвующих в процессе сторон.
Резюмируя вышесказанное, можно сделать вывод, что для повышения эффективности и востребованности сервисов аутсорсинга мониторинга и реагирования на угрозы ИБ необходимо учитывать следующие факторы:
Именно эти требования стали для нас ориентиром при пересмотре подхода к аутсорсингу информационной безопасности.
Jet CSIRT: больше, чем SOC
Убедившись в преимуществах концепции CSIRT, более широко охватывающей блок Incident Response и связанные с ним процессы, мы решили взять ее за основу обновленного подхода к аутсорсингу SOC.
Ключевым для нас стало то, что данная концепция ориентирована на реагирование и наилучшим образом подходит для предоставления услуг по сервисной модели.
Обладая одной из крупнейших в стране команд в сфере информационной безопасности и располагая десятками действующих сервисных контрактов экспертного аутсорсинга ИБ, компания запустила разработку сервисного продукта Jet CSIRT. Наличие большого количества специалистов ИБ различных профилей позволило нам реализовать гибкий подход и большой охват процессов Incident Response.
Безусловно, помимо собственного опыта создания коммерческого SOC, при создании Jet CSIRT использовался опыт и наработки других экспертных команд, а также учитывались требования законодательства и регуляторов. В частности, при построении Jet CSIRT мы руководствовались:
Стоит отметить, что FIRST Framework и NIST 800-61 определяют довольно широкий перечень сервисов CSIRT. Помимо Incident Response, в CSIRT могут быть встроены десятки сервисов и процессов: от проектирования систем ИБ, аудита и консалтинга ИБ, пентестов, всевозможной аналитики до разработки средств защиты информации. Поскольку большую часть этих задач «Инфосистемы Джет» уже успешно решает, для создания Jet CSIRT нужно было консолидировать часть уже реализуемых функций Центра информационной безопасности в единый сервисный продукт. В Jet CSIRT мы решили поместить только сервисы экспертного аутсорсинга Incident Response и эксплуатацию СЗИ.
Рисунок 5. Место Jet CSIRT в составе услуг Центра информационной безопасности «Инфосистемы Джет»
Jet CSIRT тесно взаимодействует с другими командами «Инфосистемы Джет», что позволяет включаться на любом этапе развития системы ИБ клиента и предлагать широкий перечень услуг, совмещая услуги создания, развития систем ИБ и консалтинга с услугами экспертного аутсорсинга, создавая продукты «под ключ» и обеспечивая их последующую поддержку.
Рисунок 6. Структура команды Jet CSIRT и взаимодействие с командами Центра информационной безопасности компании «Инфосистемы Джет»
Как правило, применяются две основные схемы подключения клиентов.
Рисунок 7. Схема подключения к инфраструктуре клиента: внешняя экспертиза, собственные ресурсы клиента
Первая подразумевает привлечение только экспертизы и аналитики в рамках Incident Response — за процессы отвечает команда Jet CSIRT, используя собственный инструментарий клиента. Такой подход позволяет Jet CSIRT подключаться практически ко всем популярным SIEM и СЗИ на стороне клиента. Подобная гибкость достигается благодаря большой команде Центра информационной безопасности, в которой есть эксперты по всем SIEM и СЗИ на рынке.
Рисунок 8. Схема подключения к инфраструктуре клиента: внешняя экспертиза, ресурсы Jet CSIRT
Вторая схема предполагает как использование экспертизы и аналитики Jet CSIRT, так и инструментария «Инфосистемы Джет». Ядро Jet CSIRT располагается в защищенном облаке виртуального ЦОД компании.
Таким образом, используемые источники событий Jet CSIRT и применяемый инструментарий представляют собой весьма большой и гибко изменяемый перечень.
Рисунок 9. Источники данных и применяемый инструментарий в Jet CSIRT
Уже при выполнении первых контрактов, работая с обновленной концепцией Jet CSIRT, мы на практике убедились в ее преимуществах. Так, мы отметили ускорение фаз обработки и анализа инцидентов ИБ, улучшение качества аналитики, что привело к повышению уровня удовлетворенности клиентов. Действительно, важной особенностью оказалась возможность работы с единым сервис-провайдером по очень широкому спектру задач. Например, помимо сервисов Incident Response, наши клиенты получили возможность подключения специалистов по анализу защищенности, комплексные рекомендации по развитию систем и служб ИБ, а также помощь в проектировании и настройке средств защиты.
Выводы
Таким образом, общий подход и цели Jet CSIRT можно сформулировать следующим образом:
В настоящий момент Jet CSIRT уже полноценно функционирует, и «Инфосистемы Джет» оказывает комплексные услуги экспертного аутсорсинга клиентам из самых разных отраслей. Подробнее об услугах Jet CSIRT вы можете узнать здесь.
Бизнес без опасности
Бизнес безопасности или безопасность бизнеса? О том и о другом в одном непросветительском блоге от еще неиностранного агента. Имеющий мозг да применит его (6+)
Страницы
Архив блога
Категории
5.11.15
В чем разница между CERT и CSIRT?
А я продолжаю заочную терминологическую дискуссию, навеянную Дмитрием Мананниковым, в тему предстоящего SOC Forum. На этот раз обсуждение коснется разницы между терминами CERT и CSIRT. Почему-то иногда считается, что между этими двумя аббревиатурами можно поставить знак равенства. Вроде как и одна команда (Computer Emergency Response Team) и другая (Computer Security Incident Response Team) занимаются одним и тем же. На самом деле это не совсем так.
Вчера, на конференции Cisco SecCon выступал директор по ИБ LinkedIn, у которого на слайдах было сравнение внешних и внутренних консультантов по ИБ. В случае с CSIRT и CERT ситуация будет схожая. При всей похожести того, что они делают (реагируют на инциденты), у них немного разные задачи, разные инструменты, разный масштаб.
Но в целом эта заметка в очередной раз подтверждает, что терминология в области ИБ еще не устоялась и каждый использует тот термин, который он привык использовать, даже не вдаваясь в историю его появления и область применения. Это может приводить как к забавным ситуациям, так и к непониманию между специалистами, между поставщиками услуг и их потребителями, между регуляторами и подведомственными им организациями. В том числе и об этом будет говориться на грядущем SOC Forum.
Погружение в Incident Response. Как это устроено
Время просмотра: 3 мин.
Сегодня такие инциденты происходят регулярно, что заставляет бизнес искать новые способы защиты своих информационных активов.
Кто-то сосредоточивается на обнаружении инцидентов, создавая собственный SOC или обращаясь за подобными услугами к партнерам. Это правильное решение, таким образом можно получить достаточно полную картину того, что происходит с сетью и ее информационными активами. Но полномочия SOC заканчиваются ровно в момент обнаружения инцидента. Как правило, дальнейшие шаги — сдерживание, устранение, расследование причин и принятие мер для предотвращения повторения инцидента в будущем — возлагаются на другие службы.
Ниже я поделюсь опытом, накопленным за время работы аналитиком в команде мониторинга и реагирования на инциденты ИБ Jet CSIRT.
Я представлю свое видение грамотной организации реагирования на инциденты ИБ, расскажу о задачах направления, процессах, необходимых для полноценного функционирования Incident Response, инструментах, которыми нужно пользоваться в рамках IR, приведу реальные примеры и лучшие практики, ставшие для нас ориентиром при создании CSIRT.
Статьи по теме
Поделиться
Краткая история вопроса
Термин «реагирование на инциденты ИБ» уходит корнями в 1988 г., когда Роберт Тэппэн Моррис, на тот момент 22-летний аспирант одного из вузов США, в ходе неудачного эксперимента запустил в сеть (тогда еще ARPANET) первого сетевого червя. Ущерб был настолько разрушительным, что парализовал работу около 6 тысяч узлов и фактически сделал использование сети невозможным.
В ответ на этот инцидент в Университете Карнеги — Меллона экстренно создали экспертную группу из ИБ-специалистов «Компьютерная команда реагирования на чрезвычайные ситуации» (Computer Emergency Response Team — CERT). Она должна была остановить действие вредоносного ПО.
В дальнейшем аналогичные экспертные команды CERT начали появляться по всему миру. Такие группы существуют и сегодня, однако со временем они стали фокусироваться на аналитике угроз на глобальном и региональном уровнях, как правило, в рамках отдельно взятой страны.
Тенденцию подхватили коммерческие организации, создавшие схожие группы реагирования на инциденты ИБ — Computer Security Incident Response Team (CSIRT). Эти команды должны были следить за безопасностью в рамках отдельной компании.
По опыту, для организации грамотного реагирования недостаточно просто выделить в ИТ-департаменте группу сотрудников, знающих принципы работы межсетевого экрана, назвать их CSIRT и надеяться, что отныне угрозы ИБ компании не страшны. Необходимо сформировать для группы задачи, наделить ее определенными полномочиями, обеспечить нужными инструментами и ресурсами, составить план и выстроить процессы реагирования на инциденты ИБ.
Отрицание, гнев, торг, принятие
В условиях повсеместной цифровизации, распространения IoT и BYOD можно защититься от кибератак, разве что отключив интернет, но даже в этом случае вы не будете защищены на 100%. Это значит, что жертвой киберпреступления может стать любая организация. Поэтому первым шагом на пути к защите должно стать принятие того факта, что рано или поздно вашу компанию могут взломать. Возможно, это происходит прямо сейчас, пока вы читаете эту статью. Не исключено, что в вашей сети есть критические незакрытые уязвимости, которые может проэксплуатировать злоумышленник.
Либо же в эту самую минуту ваш сотрудник открывает письмо с вредоносным вложением или вставляет в компьютер найденную в офисе USB-флешку и запускает в сеть очередной вирус-шифровальщик. Гораздо хуже, если в компании действует инсайдер, который планирует продать ваши секретные данные мошенникам.
И наконец, прямо сейчас у стен вашего офиса может быть припаркован автомобиль со шпионской Wi-Fi-точкой, к которой подключаются ваши коллеги и, сами того не зная, сливают все «пароли и явки» киберпреступникам.
Даже если ваша сеть напичкана всевозможными средствами защиты, установлены антивирусы, построен SOC, проводится регулярное сканирование на уязвимости и налажено получение актуальных TI-фидов, инцидент ИБ все равно может случиться. Но правильная организация процесса Incident Response может минимизировать возможные последствия и снизить вероятность возникновения инцидента.
Функции CSIRT
Функции реагирования у команды CSIRT гораздо шире, чем просто реакция на инцидент. Их можно разделить на 3 группы.