Коллеги, в предыдущей публикации мы рассмотрели первую часть стратегий, описанных в документе MITRE «11 стратегий SOC-центра мирового уровня». Двигаясь далее, разберем сегодня следующий набор рекомендаций MITRE: Стратегия №4 «Нанимайте и удерживайте квалифицированных сотрудников», Стратегия №5 «Приоритизируйте реагирование на киберинциденты», Стратегия №6 «Используйте киберразведку для борьбы с атакующими», Стратегия №7 «Выбирайте и собирайте правильные данные». Начнем!
Оглавление:
Стратегия №4 «Нанимайте и удерживайте квалифицированных сотрудников»
Стратегия №5 «Приоритизируйте реагирование на киберинциденты»
Стратегия №6 «Используйте киберразведку для борьбы с атакующими»
Стратегия №7 «Выбирайте и собирайте правильные данные»
Стратегия №4 «Нанимайте и удерживайте квалифицированных сотрудников»
Не секрет, что дефицит квалифицированных кадров в области ИБ является одним из основных вызовов в настоящий момент - это характерно для всего мира и для всех типов компаний, однако, при построении SOC-центра персонал, очевидно, играет ключевую роль, поэтому вопрос найма, обучения, поддержки, удержания квалифицированных работников SOC стоит двойне остро. В стратегии №4 авторы MITRE обсуждают задачи по найму и обучению сотрудников, по созданию возможностей по развитию компетенций персонала, по планированию замены работников, по планированию штатного расписания SOC и масштабированию численности сотрудников.
1. Кого набирать в SOC?
У потенциальных кандидатов на членство в команде SOC может быть совершенно разный бэкграунд, опыт, образование и навыки. При этом важны не только так называемые "hard skills" (знания и навыки в предметной области по защите информации), но и "soft skills" (личностные качества, навыки эффективного общения, взаимодействия, обработки и анализа получаемой информации).
1.1. Образ мышления и soft skills
Работа в SOC-центре подразумевает высокую интенсивность труда и самоотдачу, которая невозможна без полного погружения в профессию, которая, в идеальном случае, должна быть личным увлечением работника, что поможет ему сохранять энтузиазм и воспринимать борьбу с киберпреступностью как своеобразный личный вызов и соревнование с атакующими. Другими важными личностными навыками могут быть интуиция (которая, как правило, приходит с приобретением большого эмпирического опыта), нестандартное (нешаблонное) мышление, внимание к деталям с одновременным макро-видением ситуации в целом, возможность быстрого усвоения информации, критическое и креативное мышление, стрессоустойчивость и навыки эффективной работы в условиях недостатка времени, сопричастность и лояльность миссии SOC, стойкое желание выиграть битву с киберпреступниками. Кроме этого, для члена SOC очень важно быть командным игроком, что включает в себя хорошие навыки общения, оценку интересов коллектива выше своих личных, готовность принятия ответственности и за успехи, и за неудачи, позитивное восприятие обоснованной критики, эмоциональный интеллект и управление стрессом, навыки тайм-менеджмента и управления конфликтами, инициативность, четкое мышление и однозначные высказывания при взаимодействии. Для более опытных сотрудников важно также уметь передавать свои идеи, находки, знания и навыки коллегам, строить устойчивые взаимоотношения с коллегами и работниками компании-заказчика, возможность мыслить, как атакующий, и понимать особенности бизнеса компании-заказчика, готовность к поиску новых решений и повышению эффективности защиты, желание делиться знаниями с коллегами, проводить обучения и тренинги. Кроме того, для долгосрочного успеха SOC выигрышной будет стратегия привлечения и внутреннего обучения новых талантов - ими могут быть знакомые и друзья действующих членов команды SOC.
1.2. Предыдущий опыт и навыки кандидата
С появлением специализированных, современных программ по обучению кибербезопасности в учебных заведениях, формальное требование о наличии у кандидата определенного опыта в ИТ/ИБ может быть излишним, лучше обращать внимание на опыт участия в CTF-соревнованиях, участия в развитии Open Source проектов, пройденную практику в ИБ-отрасли. На позиции в SOC кандидаты могут прийти из смежных ИБ-областей, а также кандидаты с опытом в технической поддержке, разработке ПО, системном администрировании. Однако, обращать внимание стоит не только на кандидатов, имеющих опыт в ИТ или в ИБ - авторы публикации утверждают, что на практике встречали примеры успешных работников SOC и без профильного образования, которые пришли, например, из гуманитарных профессий. Также при поиске кандидатов не питать иллюзий о том, что найдется кандидат, который будет экспертом во всех предметных областях SOC - скорее, нужно сосредоточиться на формировании команды с взаимно дополняющими друг друга знаниями и навыками. Не стоит заострять особое внимание на специфичных навыках или работе с определенными СЗИ - такой подход отсечет потенциальных успешных кандидатов по формальным признакам, лучше фокусироваться на общих технических навыках и знаниях, мышлением, стремлением к развитию, soft skills, умению работать в команде.
1.3. Руководители SOC
Задача найти грамотного руководителя для SOC является нетривиальной: кандидат должен не только быть погружен в специфику работы и операций SOC, но и обладать управленческими навыками, методами работы с персоналом, быть квалифицированным в предметной области, быть достаточно стрессоустойчивым для принятия и согласования сложных решений в условиях недостатка времени. При этом руководителю потребуется внимательно работать с конфиденциальной информацией, обучать и мотивировать персонал, видеть траекторию развития SOC, работать с руководителями компании на всех уровнях и отвечать на их вопросы, воспринимать обратную связь и непрерывно повышать квалификацию.
1.4. Общие рекомендации по найму команды SOC
При создании команды SOC следует привлекать к найму HR-специалистов, которые будут управлять процессом поиска и найма кандидатов, включая поиск резюме, размещение вакансий, выбор кандидатов для собеседований, проведение собеседований, принятие решений о приеме на работу, согласование уровня компенсации. Следует также планировать бюджет для непрерывного поиска и найма новых сотрудников, поскольку SOC будет меняться со временем, также как и сотрудники, которые будут и увольняться, и повышать компетенции для повышения своих знаний в соответствии с актуальным киберугрозам.
2. Инвестируйте в развитие своих сотрудников в SOC
Несмотря на большое количество курсов, программ повышения квалификации, новых ИБ-специализаций в учебных заведениях, компании по-прежнему сталкиваются с дефицитом квалифицированных кадров, и выходом из ситуации может стать внутреннее развитие сотрудников SOC. Кроме инвестиций в поиск и привлечение уже опытных ИБ-специалистов, окупающимися затратами будут также внутренние программы обучения, развитие сотрудников за пределами их текущих позиций, проведение внешних обучений для работников - причем такие инвестиции нужны и для начальных позиций, и для опытных сотрудников ввиду непрерывной эволюции ИБ-отрасли и изменения ландшафта киберугроз. Авторы публикации подчёркивают, что подобные инициативы требуют последовательных инвестиций времени и ресурсов, но в конечном итоге обеспечат устойчивое развитие и успех SOC в долгосрочной перспективе. Преимуществами развития внутренней экспертизы будут управляемость процесса, контроль областей, в которых требуется повышать компетенции, а также возможность внутреннего обмена знаниями и менторства со стороны опытных членов команды SOC. Предметными областями, в которых требуются компетенции, могут быть анализ сетевых вторжений, развертывание и настройка СЗИ (например, SIEM или EDR), форензика, анализ и эксплуатация уязвимостей, тестирование на проникновение, анализ ВПО и реверс-инжиниринг, управление ОС, БД и сетевым оборудованием, облачными инфраструктурами. При этом персоналу SOC важно соблюдать баланс между глубиной и широтой познаний. Например, администратор СЗИ должен глубоко знать свою предметную область и в целом иметь представление о смежных направлениях (что делают аналитики ВПО и пен-тестеры, например); также целесообразно развивать компетенции, соответствующие особенностям инфраструктуры заказчика (типы эксплуатируемых ОС, СЗИ, сетевого оборудования).
2.1. Обучение на рабочем месте, введение новых сотрудников в должность
Найм кандидатов с небольшим опытом, но с высоким потенциалом, может быть выигрышной стратегией, с учетом дефицита опытных сотрудников. Для ввода новых сотрудников в должность и их быстрое погружение в работу SOC следует разработать внутреннюю программу обучения (адаптации), которая может включать в себя как формальные, так и неформальные аспекты. План обучения может включать в себя техническое обучение работе с инструментарием SOC, интерактивное практическое обучение, теоретическая подготовка, проведение практикумов по работе с реальными или тестовыми данными для выполнения типовых действий члена команды SOC, изучение TTPs конкретных атакующих, погружение в бизнес-процессы, инфраструктуру, технологии компании-заказчика, расширенное использование инструментария SOC, изучение трендов кибератак. Обучения такого типа полезны с точки зрения передачи опыта и знаний новым сотрудником от более опытных коллег.
2.2. Проведение кросс-тренингов и ротация работников
Кросс-тренинги проводятся для различных членов команды в целях погружения в работу смежных команд/подразделений/ролей - чем больше члены команды SOC знают о функционале друг друга, тем лучше они понимают свою роль в общей работе и выполнении миссии SOC; подобное обучение также поможет временно закрыть функции заболевшего или неожиданно уволившегося работника, а также позволит избежать монотонности в работе и по-новому взглянуть на работу SOC. Ротация персонала будет особенно полезной для небольших SOC или SOC, работающих по безуровневой модели; позиции для ротации членов команды SOC могут включать в себя функционал разработки сигнатур и правил корреляции, аналитики и обработки данных о киберугрозах, администрирования и настройки СЗИ SOC, а также дежурство по принципу «аналитик дня/недели» в небольших командах. Такая ротация позволит сотрудникам лучше понять работу SOC, процессов и используемых технологий, а также понять работу коллег по SOC и оптимизировать работу в своей зоне ответственности.
2.3. Внешние обучения
Для расширения кругозора, повышения квалификации, более глубоко познания используемых технологий, а также для обмена знаниями с коллегами по индустрии целесообразно проводить внешние обучения, которые, однако, не должны быть заменой внутренних программ обучения. Авторы публикации приводят в качестве примера ряд вендорских и вендоронезависимых курсов обучения, а также перечень наиболее популярных конференций по кибербезопасности.
3. Создавайте благоприятную рабочую среду, мотивирующую работников к долгосрочному сотрудничеству
Сохранение команды квалифицированных работников SOC является одной из самых сложных задач. По сведениям авторов публикации, самыми часто озвучиваемыми причинами сохранения текущего места работы для работников SOC являются их осознание команды SOC как сплоченного, дружного коллектива высококвалифицированных, мотивированных профессионалов, а также возможность ежедневной работы с интересными задачами с высокой степенью свободы в принятии решений и глубокая вера в глобальную, уникальную и важную миссию обеспечения кибербезопасности. Кроме этого, руководителям SOC следует учитывать перечисленные ниже факторы, способствующие удержанию работников и снижению текучки кадров.
3.1. Обеспечьте справедливую материальную компенсацию на уровне рынка
Мотивированный и способный новый член команды SOC, пришедший на начальную позицию, за 1-2 года может получить необходимый опыт и затем перейти в другую компанию в погоне за более высоким уровнем оплаты. Причиной может являться неадекватный, по мнению работников, уровень оплаты их труда, который может быть ниже среднего по рынку. Также следует давать возможность высококвалифицированным сотрудникам получать адекватную заработную плату без необходимости исключительно финансово-мотивированного перехода на руководящие позиции. Однако, добившись адекватного финансового обеспечения команды, руководителям следует обратить внимание на иные факторы, повышающие коэффициент удержания сотрудников.
3.2. Поддерживайте карьерный и профессиональный рост работников
Страсть к работе, профессиональный энтузиазм и стремление к преодолению новых вызовов являются одними из самых предпочтительных личных качеств сотрудника SOC. При этом важно понять, что именно мотивирует каждого члена команды - вертикальный рост (повышение в должности, руководящие роли) или горизонтальный рост (приобретение новых компетенций, расширение профессионального кругозора). При составлении «дорожной карты» обучения сотрудника важно понимать, желает ли работник развиваться дальше в текущем направлении или хочет переключиться на другую позицию в SOC, а затем распланировать тренинги на долгосрочную перспективу для понимания сотрудником своего карьерного трека.
3.3. Поощряйте автоматизацию и развитие технических возможностей
Рутинные задачи и неоднократно повторяемые действия могут привести к демотивации членов команды SOC, поэтому важно предоставлять возможность сотрудникам развивать свои технические навыки в области автоматизации и аналитики процессов SOC. При автоматизации высвобождаются ресурсы команды, что благотворно влияет и на дальнейший прогресс автоматизации, и на заинтересованность сотрудников. Высокий уровень автоматизации действий работников SOC достигается за счет использования и поддержки актуального технического инструментария: членам команды требуется предоставить набор современных, удобных технических инструментов, которые соответствуют текущим киберугрозам. Авторы публикации рекомендуют учесть следующие аспекты:
Следует выстроить структуру, повторяемость и автоматизацию процессов анализа и расследования киберинцидентов, например, путем использования SOAR платформ и интерактивных средств работы аналитиков для автоматизации рутинных задач;
Следует использовать автоматизированные средства предотвращения кибератак (в случае экономической целесообразности и применимости таких решений), например, EDR-системы, что позволяет снизить количество рутинных операций, отнимающих ресурсы команды;
Необходимо вносить изменения в систему управления ИБ компании-заказчика для исправления стратегических проблем кибербезопасности, которые выявляются SOC-центром, что позволит избежать повторяющихся инцидентов и повысит уровень удовлетворенности работников SOC от видимых улучшений состояния киберзащищенности заказчика;
Рекомендуется обеспечить высокий уровень автоматизации, повторяемости, шаблонизируемости реагирования на типовые киберинциденты с тем, чтобы их обработка занимала минимальное время и могла осуществляться младшими членами команды SOC;
Рекомендуется передавать процедуры реагирования на некоторые виды типовых инцидентов другим подразделениям компании-заказчика (отдельно от SOC могут обрабатываться, например, внутренние киберугрозы, включая действия инсайдеров);
Следует способствовать развитию функционала SOC силами самих сотрудников (включая проактивный поиск киберугроз, анализ и исследование киберугроз, развитие методов и инструментов машинного обучения для помощи при анализе инцидентов);
Планируйте и предоставляйте возможности для внутренних инициатив по повышению профессиональных навыков, например, в рамках работ по поиску киберугроз или Purple Teaming-мероприятий (совместная работа атакующих из Red Team и защитников из Blue Team для обмена опытом).
3.4. Непрерывно взаимодействуйте и общайтесь с коллегами.
Одними из главных мотиваторов для работников SOC являются командная работа и чувство сопричастности к общему важному делу, следовательно, для повышения морального духа команды важным является предоставление обратной связи работникам SOC о важности и результатах их работы. Для такого взаимодействия можно проводить регулярные встречи команды SOC - как ежедневные или еженедельные короткие планерки для обсуждения текущих задач, так и более широкие встречи каждый месяц или раз в квартал для обсуждения стратегических вопросов. Также можно давать обратную связь всему SOC по результатам обработанных инцидентов для того, чтобы каждый сотрудник понимал свой вклад в успех общего дела, для обмена знаниями и техниками работы с инцидентами, для актуализации знаний всех членов команды SOC о состоянии ландшафта обрабатываемых киберугроз, а также для улучшения работы всего SOC. Важным способом обмена информацией также являются горизонтальные связи в команде SOC, которые помогают коллегам обмениваться знаниями для достижения синергетического эффекта при работе над инцидентами.
4. Подготовьтесь к текучке кадров заранее
Для того, чтобы с минимальными потерями пройти период от увольнения сотрудника до найма нового, руководителям SOC следует заранее подготовиться к подобным ситуациям, прежде всего за счет организации тщательного документирования всех процедур реагирования и накопления базы знаний; при этом важно, чтобы ключевые сотрудники и руководители SOC обладали большим багажом знаний для закрытия «пробелов» в команде на период найма новых работников.
5. Формализуйте процедуры SOC
При формализации деятельности SOC важно соблюсти баланс между четко выстроенным структурированным подходом к реагированию и степенью творческой свободы аналитиков при работе, особенно с нетиповыми, уникальными инцидентами. Создавать стандартизированные операционные процедуры (SOP, standard operating procedure) рекомендуется для таких повторяющихся действий, как проверка данных в консолях и фидах СЗИ, контроль работоспособности технологического стека SOC, проверка актуальности информации на дашбордах и в отчетах, анализ доступности веб-ресурсов, являющихся источником информации для SOC. Важно также заранее разработать детальные SOPs для процедур эскалации как типовых, некритичных инцидентов, так и необычных, критичных инцидентов ИБ (отметим, что процедуры эскалации могут включаться в сценарии реагирования на киберинциденты).
6. Расчет количества работников SOC
Расчет необходимого числа членов команды SOC зависит от множества факторов, но в общем случае эффективность SOC больше зависит от квалификации аналитиков, зрелости процессов и уровня автоматизации в SOC. Авторы публикации указывают, что количество работников SOC может зависеть от количества защищаемых активов и пользователей компании-заказчика, размеров и географической распределенности филиалов компании-заказчика, уровня гетерогенности защищаемой инфраструктуры, от целей SOC и спектра предоставляемых заказчику услуг, от количества регистрируемых киберинцидентов, организационной модели SOC, уровня сложности и распределенности используемых технологий SOC, уровня желаемых и имеющихся компетенций персонала SOC, режима работы SOC (8x5, 12x5, 24x7 и т.д.), уровня автоматизации процессов в SOC, а также от бюджета SOC. При расчете кадрового обеспечения конкретной функции/услуги можно руководствоваться следующими рекомендациями авторов:
1. Мониторинг и категорирование в режиме реального времени: количество работников зависит от количества поступающих событий и предупреждений, а также от уровня автоматизации процессов категорирования инцидентов.
2. Анализ и расследование инцидентов: количество работников зависит от количества регистрируемых инцидентов, квалификации аналитиков и доступного им инструментария.
3. Обработка данных о киберугрозах, поиск киберугроз: количество работников зависит от оценки уровня киберрисков компанией и возможностей компании по снижению уровня рисков путем инвестиций в данную функцию SOC.
4. Сканирование на наличие уязвимостей: количество работников зависит от количества сканируемых и контролируемых информационных систем и сложности ИТ-инфраструктуры, эффективности сканеров и сложности работы с ними.
5. Анализ уязвимостей, симуляция атак и проведение аудитов: количество работников зависит от уровня киберрисков компании, которые влияют на требуемую частоту и объемы работ.
6. Разработка и управление используемыми в SOC средствами защиты: количество работников зависит от числа инсталляций и количества сенсоров, от разнообразия используемых СЗИ, уровня автоматизации в каждом СЗИ, возможности централизованного управления СЗИ, а также от организационных требований к процессам управления технологиями.
7. Разработка и управление используемыми в SOC технологиями: количество работников зависит от сложности применяемых в SOC систем и решений, скорости предоставления новых услуг SOC заказчикам, наличия разработанных внутри SOC технологий и сложности их развития и поддержки, выполнения функций системного администрирования и разработки внутри SOC или с помощью сторонних подразделений.
8. Управление SOC: количество сотрудников руководящего звена зависит от размеров SOC, стандартов и практик компании-заказчика.
Стратегия №5 «Приоритизируйте реагирование на киберинциденты»
Реагирование на киберинциденты является ключевой функцией любого SOC, при этом зачастую под обработкой инцидентов ИБ понимают не только непосредственно реагирование (тактическая и оперативная техническая деятельность), но и управление (стратегическая деятельность, включая планирование, координирование, взаимодействие, отчетность) киберинцидентами; авторы публикации же предлагают использовать термины «реагирование» и «управление» как взаимозаменяемые.
1. Выбор фреймворков и методологий
Для подготовки плана реагирования на киберинциденты авторы рекомендуют руководствоваться следующими фреймворками:
Специальная публикация NIST SP 800-61 "Computer Security Incident Handling Guide" ( «Руководство по обработке инцидентов компьютерной безопасности»);
Специальная публикация NIST SP 800-184 "Guide for Cybersecurity Event Recovery" ( «Руководство по восстановлению после киберинцидентов»);
Классификация ENISA (Агентство ЕС по кибербезопасности) "Reference Incident Classification Taxonomy" ( «Справочная классификация инцидентов»);
Классификация типов киберинцидентов Open Source платформы MISP;
Концепция OODA ("Observe, Orient, Decide, Act", т.е. «Наблюдайте, ориентируйтесь, принимайте решение, действуйте»).
В целом, подход к управлению киберинцидентами, на который ориентируются авторы публикации MITRE, заключается в цикле «Подготовка, планирование - Выявление, анализ - Сдерживание, устранение, восстановление - Пост-инцидентные действия». В соответствии с этим циклом и строится описание рекомендаций в Стратегии №5.
2. Планирование
Грамотное планирование поможет добиться эффективного, результативного, релевантного и комплексного реагирования в момент наступления киберинцидента, при этом меры реагирования должны соответствовать уровню критичности ситуации. Для подготовки к большинству инцидентов SOC-центру потребуются:
Сотрудники с сильными техническими, аналитическими, коммуникативными навыками;
Документальное обеспечение: стандартизированные операционные процедуры (SOP, standard operating procedure), концепция операционных процедур (CONOPS, Concept of Operations) SOC-центра (т.е. описание того, как работает SOC-центр, какими полномочиями обладает и какую ответственность несет персонал SOC, описание ролевой модели, функций, возможностей, требований SOC-центра), а также описание процедур эскалации;
Средства координации действий по анализу и реагированию членов команды SOC;
Перечень ответственных лиц, с которыми требуется координировать действия по реагированию на инцидент, и их контактных данных;
Инструменты для сбора и анализа артефактов для выявления фактов, относящихся к киберинцидентам;
Полномочия для выполнения оперативных и решительных действий, а также для понижения уровня критичности инцидента, деэскалации и пассивного мониторинга в случае необходимости.
В план реагирования могут быть включены такие документы, как:
Описание ролей и ответственных членов команды реагирования, с указанием зон ответственности, включая контакты аутсорсеров;
Контакты, способы взаимодействия, список координаторов для понимания, кто, когда и как должен быть уведомлен, включая внутренних и внешних контактных лиц, а также представителей юридического департамента и сотрудников правоохранительных органов;
Справочная документация, руководства, описание выполняемых процедур, таких как SOP, руководства по формированию отчетности, применимые политики;
Описание инструментов, технологий и физических ресурсов, используемых SOC, с описанием способа получения доступа к ним;
Перечень критичных процессов восстановления сетей и данных, включая подробные инструкции по восстановлению;
Ссылка на Устав SOC и иные документы, которые закрепляют за SOC определенные полномочия, использующиеся при реагировании.
Перед приоритизацией типов инцидентов следует сначала составить весь перечень ожидаемых и моделируемых кибератак, включая как самые частые и известные типы, так и происходящие редко, но опасные. В отечественных реалиях перечень типов инцидентов можно составить на основе актуализированной модели угроз, а также можно руководствоваться методическими рекомендациями, в частности, из БДУ ФСТЭК России. Кроме того, авторы публикации рекомендуют использовать данные из матрицы MITRE ATT&CK при формировании списка инцидентов, с указанием приоритета для каждого типа киберинцидента/нежелательного (недопустимого) события ИБ, а также с кратким описанием способов реагирования. При этом, разумеется, для каждой организации и инфраструктуры подобный перечень будет уникальным, как и приоритет и способ реагирования.
Способы и шаги по реагированию для релевантных типов инцидентов подробно описываются в руководствах по обработке инцидентов - плейбуках (playbooks) или сценариях реагирования, которые требуются для упорядочивания реагирования и повторяемости, шаблонизируемости действий членов команды SOC-центра. Это также важно и для новых сотрудников, которым будет проще войти в должность, и для опытных сотрудников, которым не придется каждый раз «изобретать велосипед» при реагировании, а можно будет уделить внимание новым особенностям и деталям инцидента. Грамотно составленные описания последовательности выполняемых при реагировании действий (сценариев реагирования) также являются ключевым фактором успеха при автоматизации действий по реагированию.
Авторы публикации рекомендуют разрабатывать сценарии для всех типов инцидентов, которые обрабатываются в SOC не реже одного раза в месяц. В плейбуке, как правило, должны быть указаны название сценария, решаемая задача и область применимости, условия задействования сценария, выполняемые процедуры и шаги реагирования, а также метаданные самого документа (номер версии, автор, история пересмотра). Сценарии реагирования должны не только соответствовать бизнес-процессам и информационной инфраструктуре Заказчика, но и сохранять баланс между подробным описанием действий и предоставлением сотрудникам SOC необходимой творческой свободы при реагировании. При этом важно включать в сценарий чек-лист, по которому будет удобно сверяться и новичку, и опытному эксперту SOC-центра для того, чтобы не забыть выполнить все обязательные при реагировании действия.
Разработанные сценарии необходимо регулярно актуализировать по результату пост-инцидентных действий для обеспечения непрерывности процесса совершенствования реагирования, а актуальные версии плейбуков лучше хранить в единой базе знаний с быстрым и удобным поиском и совместным использованием.
3. Выявление и анализ
Процессы выявления и анализа киберинцидентов можно разделить на три группы: изучение инцидентов (т.е. триаж, включающий в себя получение, сортировку, категоризацию, приоритизацию инцидентов), анализ инцидентов (анализ событий и инцидентов в целях проведения расследования), расследование (выяснение источников и причин инцидентов, ведение отчетности).
3.1. Триаж инцидентов
Сообщения о возможных инцидентах могут поступать в SOC различными способами: по email, по телефону, в виде заявок в ИТ, от контрагентов, а также от инструментов мониторинга самого SOC. При поступлении входящей информации часто непонятно, является ли поступившее предупреждение или сообщение признаком инцидента или нет, поэтому для проверки входящего сообщения и определения типа инцидента выполняются процедуры триажа. Группировка и категорирование инцидентов выполняются в каждом SOC по-разному ввиду отличий в бизнес-процессах и инфраструктуре, но авторы публикации приводят следующие примеры и рекомендации для корректного триажа инцидентов:
Категорировать инциденты можно в зависимости от векторов атаки и влияния на активы компании, но при использовании при атаке различных тактик и техник категории может возникнуть путаница.
Можно выбирать категории инцидентов в зависимости от применимых мер реагирования (например, меры реагирования на кибератаки на веб-приложения будут отличаться от реагирования на заражение ВПО или DDoS-атаку).
Можно выбирать категории инцидентов в зависимости от организационных подразделений, которые будут участвовать в реагировании (например, при фишинге это будут администраторы email-сервиса, а при атаке на веб-сайт - администраторы веб-приложений).
Следует определить типы категорий инцидентов до момента наступления инцидента для упрощения планирования, при этом всегда можно будет добавить новые типы в дальнейшем.
Следует разработать руководства по триажу инцидентов для оперативности и во избежание образования очереди входящих инцидентов, которые медленно обрабатываются сотрудниками SOC.
3.2. Анализ инцидентов
При рассмотрении нового инцидента важно использовать информацию из различных источников для формирования более полной, целостной картины того, что произошло. Авторы публикации дают следующие рекомендации для анализа инцидентов:
Проверяйте предположения и гипотезы, основываясь на фактах, а не на домыслах.
Ищите свидетельства и данные, которые дополнят картину произошедшего, даже если они находятся вне «поля зрения» SOC.
Анализируйте индикаторы компрометации (хэши, IP/URL-адреса, дампы трафика и т.д.) для получения полной картины использовавшихся атакующими TTPs.
Создавайте временной график (timeline) релевантных событий для понимания действий атакующих и этапов атаки.
Используйте сравнение известных и неизвестных программных компонентов, например, путем использования списка «известных хороших» хэшей системных файлов или сертификатов доверенных издателей для сравнения с данными подозрительных файлов.
Не опирайтесь только на индикаторы компрометации, поскольку атакующие легко могут изменить хэши, IP/URL-адреса и т.д., следовательно, рекомендуется строить TTPs-модели атакующих и использовать индикаторы атак для более точного анализа поведения злоумышленников и их конечных целей.
Анализ сценариев и гипотез атак на основе уже имеющихся фактов помогает выстроить предположения о дальнейших действиях атакующих и проводить поиск дополнительной информации об атаке.
Избегайте предвзятости и предубеждений, которые могут сформироваться у аналитиков на основании некоего опыта, когда кажется, что все инциденты одного типа в чем-то похожи; авторы документа рекомендуют рассматривать каждый инцидент как абсолютно новый, поскольку каждая кибератака будет в чем-то уникальной, что потребует и соответствующей корректировки мер реагирования.
3.3. Расследование
При реагировании использование форензики (компьютерной криминалистики) сводится к выявлению подозрительной или вредоносной активности, которая может быть связана с рассматриваемым инцидентом. Для получения информации об активности можно использовать данные из СЗИ, сетевого оборудования, конечных устройств, руководствуясь рекомендациями вендоров и публикациями о форензике соответствующих классов активов и операционных систем. Авторы документа считают, что самые ценные и непротиворечивые данные об инциденте можно получить с конечных точек и информационных систем (в том числе с использованием EDR-решений), с которых следует передавать события ИБ в защищенные хранилища во избежание несанкционированного их изменения атакующими. Выявление «нулевого пациента», с которого началось горизонтальное перемещение атакующих в инфраструктуре, поможет выявить в сети атакованные активы, направление движения атакующих и их цели, а также предпринять соответствующие действия. Авторы публикации рекомендуют анализировать следующие артефакты:
Файловая система и файлы, с поиском неизвестных каталогов, файлов, объектов;
Запущенные процессы, с анализов неизвестных процессов и поиском аномалий в поведении известных процессов;
Скрипты, исполняемые файлы;
Хэши системных файлов, не соответствующие «известным хорошим» хэшам, а также данные о цифровой подписи файлов, не соответствующие известным доверенным издателям;
Системные журналы аудита, с поиском активности неизвестных учетных записей, изменений привилегий, фактов создания новых доверенных хостов, существенных изменений файлов;
Сетевая активность, включая VPN-подключения, удаленные подключения, создание туннелей, использование RDP и SSH, которые могут использоваться для создания атакующими несанкционированного канала передачи данных и команд.
При анализе и расследовании инцидентов члены команды SOC часто сталкиваются с большим количеством ложноположительных срабатываний, которые превышают по численности истинноположительные («боевые») срабатывания в большинстве систем обнаружения кибератак, поэтому важно непрерывно проводить донастройку (тюнинг) СЗИ, обогащать контекст событий, использовать средства автоматизации. Зачастую в SOC применяется также такая категория сработки, как «не угроза» или «доброкачественное» срабатывание (англ. benign positive) - в этом случае средство обнаружения верно зафиксировало истинноположительное событие, которое после проверки оказалось не вредоносным; такое может встречаться при обнаружении активности санкционированных пен-тестов или при объективно подозрительном поведении пользователей или устройств, которое после проверки оказалось легитимной активностью.
Авторы публикации также дают членам команд SOC-центров свои рекомендации по эффективному и результативному анализу аномалий и косвенных признаков сложных кибератак:
Оставайтесь спокойными: в ситуации обнаружения признаков или последствий кибератаки пользователи могут преувеличивать масштаб проблемы, задача SOC в этом случае - спокойно, объективно и квалифицированно разобраться в ситуации перед выполнением реагирования.
Заранее наладьте взаимодействие с правоохранительными органами и внутренней юридической службой: в случае наступления инцидента, требующего выполнение юридически значимых действий, взаимодействие с профильными специалистами очень поможет.
При реагировании общайтесь с пользователями, владельцами систем и сервисов, системными администраторами: сотрудники могут подсказать, какие странности или аномалии они заметили в информационных системах.
Предусмотрите возможность обращения к экспертизе за пределами SOC: при наступлении масштабного инцидента или при возникновении сложностей при анализе (например, необходимость реверс-инжиниринга), у SOC может не оказаться достаточных ресурсов для выполнения задач, поэтому полезно будет заранее договориться о взаимодействии со сторонними лицами, например, с другим SOC или интегратором/вендором.
Контекстуализируйте информацию: при анализе инцидента следует понять, что означает та или иная активность в контексте работы бизнес-процесса, сервиса, информационной системы, какие события предшествовали инциденту, являются ли зафиксированные события характерными или аномальными, где произошли события, какие источники могут дать еще больше контекста.
Избегайте поспешных выводов и предположений: при обработке инцидента следует предварительно изучить содержимое событий, данных сетевого взаимодействия, артефактов перед вынесением суждения относительно природы инцидента, поскольку неверное предположение может привести к затратам времени и ресурсов, а также к падению репутации.
Отличайте факты от предположений: следует заранее внедрить техники для анализа и проверки доказательств, корреляций и причинно-следственных связей.
Не делайте чрезмерный акцент на атрибуции, но старайтесь ассоциировать атакующих с инцидентом: несмотря на пользу сопоставления текущего инцидента с предыдущими и с группами атакующих, поспешные неверные гипотезы о связях могут привести к неверному реагированию; при этом для корректного реагирования на уже известную активность не обязательно проводить доскональное атрибутирование атаки.
4. Сдерживание, устранение, восстановление
При выполнении действий по реагированию возможны совершение ошибок и реализация неэффективных контрмер, которые сами могут привести к нанесению ущерба компании (например, остановка критичных сервисов) или нецелевому расходованию существенных ресурсов. Авторы публикации дают ряд рекомендаций для проведения корректного сдерживания, устранения, восстановления:
Обеспечьте согласованное движение к общей цели в SOC: в самый разгар реагирования на критичный киберинцидент члены SOC могут превысить свои полномочия и предпринять контрмеры, которые навредят компании (например, потребовать отключить критичный сервер или бизнес-сервис); для избежания таких ошибок следует выстроить взаимодействие внутри SOC, работу с сотрудниками и руководителями компании, обеспечить четкую структуру подчиненности внутри SOC.
Постройте структуру управления: следует заранее разработать систему подчиненности, определить границы зон ответственности, выстроить взаимодействие внутри команды SOC, а также назначать ответственного за каждый киберинцидент.
Не станьте жертвой «тумана кибервойны»: при реагировании (особенно на сложные, многовекторные кибератаки) убедитесь, что собраны точные и полные детали киберинцидента, т.к. без этого невозможно полностью устранить последствия атаки и не допустить ее повторения.
Готовьтесь давать ответы на вопросы типа «И что?»: при донесении информации о киберинциденте топ-менеджменту и собственникам компании важно не вдаваться в технические термины, а объяснять ситуацию с точки зрения бизнеса, достижения целей компании, финансовых затрат; следует приготовиться к ответам на вопросы о том, что было атаковано, была ли атака успешной, кто стоит за ней и какова их мотивация, как продолжать бизнес-процессы.
Отчитывайтесь тогда, когда вы готовы: несмотря на то, что при наступлении инцидента и реагировании на него будет множество желающих получать оперативные и частые доклады о ситуации, следует предварительно определить временные рамки и получателей отчетов об инцидентах; при реагировании на серьезный инцидент авторы публикации рекомендуют проводить два отдельных совещания каждые один-два дня: на первом совещании могут присутствовать непосредственные участники реагирования, на втором - руководители, которым будет сообщаться более высокоуровневая информация.
Перед выполнением мероприятий по активному реагированию, сдерживанию, устранению киберугрозы следует предварительно убедиться в том, что у команды SOC есть вся необходимая информация. Следует выяснить, не затронут ли планируемые контрмеры и действия по реагированию легитимные критичные бизнес-процессы - для этого нужно связаться с соответствующими работниками компании и уточнить у них подробности. Нужно также определить весь масштаб атаки и затронутые инцидентом активы, поскольку поспешное реагирование может привести к некорректной оценке числа затронутых инцидентом активов, не устраненному присутствию атакующих в инфраструктуре и, возможно, к попыткам атакующих более надежно скрыть свои действия, чтобы стать более незаметными.
Кроме того, в определенных случаях могут потребоваться привлечение юристов и сбор юридически значимой доказательной базы при обнаружении признаков состава киберпреступления - в этом случае нужно соблюсти баланс между полнотой сбора доказательств, понимания целей злоумышленников и недопущением критичного ущерба в результате продолжающейся кибератаки. Авторы публикации подчеркивают, что при реагировании важно руководствоваться не только стремлением устранить угрозу и «выкинуть» атакующих из инфраструктуры, но и продумать негативные последствия выполняемых активных действий по реагированию («перезаливка» серверов приведет к недоступности сервисов и может привести к утере форензик-артефактов, завершение процессов может дать только временный эффект, а смена учетных данных может не дать эффекта, если у атакующих есть доступ к различным аккаунтам или если токен доступа остается действительным еще какое-то время).
В рамках реагирования также важно использовать централизованную систему для совместной работы членов команды SOC, контроля их действий и отслеживания прогресса при реагировании на киберинциденты; при этом учет и контроль инцидентов в разрозненных системах или электронных таблицах может только привести к путанице и дезорганизации. В единой системе контроля и учета киберинцидентов (системе трекинга), как минимум, должны указываться такие сведения, как общая информация по инциденту и детали, временной график развития инцидента и выполняемых действий, имя и контактные данные ответственного, выполненные и выполняемые действия по реагированию, актуальный статус киберинцидента. При реагировании членам команды важно придерживаться разработанных сценариев и SOPs, а после закрытия инцидента следует обновлять базу знаний на основе «выученных уроков» каждой кибератаки и соответствующего реагирования.
5. Пост-инцидентные действия
Регулярное пополнение централизованной базы знаний и решений по результатам анализа «выученных уроков» произошедших киберинцидентов и выполненных мер реагирования, а также последующее изменение соответствующих процедур и сценариев реагирования напрямую влияют на возможности SOC по выполнению возложенных на него задач. Пост-инцидентный обзор (review) закрытого инцидента, по мнению авторов публикации, должен включать в себя обсуждение следующих вопросов:
Какие меры и действия помогли при реагировании?
Какие меры и действия не помогли при реагировании?
Что замедляло реагирование?
Была ли путаница? Когда и где, как ее избежать в дальнейшем?
Был ли у ответственных лиц доступ к необходимой информации?
Были ли выявлены отсутствующие, но требовавшиеся инструменты, были ли инструменты недоступны, были ли имеющиеся инструменты бесполезны?
Каких инструментов или данных было недостаточно для успешного реагирования?
Кто должен был быть вовлечен в реагирование на инцидент (но не был)?
Какие навыки были нужны, а какие реально использовались?
Хорошо ли отработали оповещение и отчетность?
Собранная информация должна подаваться «на входе» этапа планирования для повышения эффективности SOC, корректировки инвестиционных стратегий, найма работников с нужной экспертизой. Выявленные в результате реагирования недостатки в системе управления ИБ компании-заказчика также нужно регулярно и системно передавать ответственным лицам для улучшения состояния киберзащищенности и недопущения аналогичных инцидентов в дальнейшем. При формировании и назначении на ответственного перечня обнаруженных недостатков в системе управления ИБ компании-заказчика следует обязательно давать ссылки на соответствующие инциденты, которые вскрыли данные недостатки - это поможет более структурно работать над улучшением состояния ИБ в компании и позволит не допустить систематического повторения одних и тех же ошибок в киберзащите, а также даст возможность членам команды SOC-центра увидеть результаты собственных усилий по повышению защищенности.
Стратегия №6 «Используйте киберразведку для борьбы с атакующими»
Авторы публикации указывают на связь любой серьезной атаки с конкретной группой атакующих, и методы киберразведки (аналитики киберугроз) позволяют ассоциировать наблюдаемые события ИБ или киберинциденты с злоумышленниками для более глубокого понимания целей и возможных средств атаки, поскольку у каждой из киберпреступных групп есть свой «почерк», характерные TTPs и инструменты. Стратегия №6 посвящена методам применения киберразведки в деятельности SOC-центра.
1. Что такое киберразведка?
По определению авторов публикации, киберразведка или аналитика киберугроз (англ. Cyber Threat Intelligence, сокращенно CTI) - это процесс сбора, обработки, упорядочивания и интерпретации полученных данных в действенную, практически применимую информацию или продукты, которые позволяют понять возможности, способности, действия, намерения атакующих в киберпространстве. В контексте работы SOC-центров, аналитика киберугроз может применяться для понимания действий атакующих и их поведения; при этом данные киберразведки можно коррелировать с внутренними данными SOC о событиях и инцидентах ИБ, что способствует повышению видимости кибератак, снижению ущерба, повышению качества принимаемых решений при реагировании на киберинциденты.
Данные киберразведки помогут также для выявления злоумышленников внутри инфраструктуры, тонкой настройки сенсоров и аналитических систем для лучшего мониторинга, приоритизации ресурсов SOC, обогащения и контекстуализации информации по киберинцидентам, предотвращения или замедления кибератак, а также для прогнозирования поведения атакующих в сети компании. Классический цикл аналитики киберугроз заключается в планировании, сборе, обработке, анализе, распространении, оценке данных киберразведки. Применять данные киберразведки важно, т.к. такой подход позволяет перейти от реактивной модели реагирования на киберинциденты (по факту выявления признаков) к проактивной, при которой действия атакующий прогнозируются и выявляются до выполнения деструктивных или вредоносных действий, которые выявляются СЗИ. При этом источники данных киберразведки могут быть и внешние (аналитические отчеты о киберугрозах от ИБ-компаний, сведения от других SOC, поставщики данных киберразведки - фиды Threat Intelligence, сокращенно TI-фиды), и внутренние (сведения от аналитиков и исследователей внутри компании-заказчика).
По мнению авторов публикации, источник данных, относящийся к киберугрозам, может считаться источником аналитики киберугроз только в случае предоставления им информации об атакующих (контекст и детали контекста атакующих). Так, IP-адреса, доменные имена, адреса email, сигнатуры вирусов без привязки к конкретным атакующим не могут считаться CTI-данными. При этом CTI-источниками будут считаться аналитические отчеты о киберугрозах, выпускаемые вендорами и исследователями, структурированные отчеты (например, в формате STIX), данные TI-фидов. С учетом потенциального большого числа возможных источников CTI-данных, рекомендуется оценивать следующие характеристики поставляемых источником данных:
Можно ли использовать полученные данные, например, в корреляционных правилах, в сценариях проактивного поиска киберугроз (Threat Hunting), использовать в средствах предотвращения атак?
Являются ли получаемые данные актуальными и современными, нет ли среди них устаревшей информации?
Являются ли получаемые данные релевантными для инфраструктуры и сектора экономики компании-заказчика, поступают ли они из доверенного источника с хорошей репутацией, как происходит обработка и передача CTI-данных, используются ли API-интерфейсы для взаимодействия?
Являются ли получаемые данные точными и непротиворечивыми?
2. Цели и планирование использования аналитики киберугроз
Одной из целей аналитики киберугроз является оказание помощи руководителям компании для фокусирования их внимания на значимых киберугрозах и принятия взвешенных, риск-ориентированных управленческих решений. Поскольку руководители могут находиться на различных иерархических уровнях в компании, предоставляемые им данные киберразведки также распределяются по различных уровням в зависимости от глубины детализации и целей:
Стратегический уровень, на котором информациях предоставляется топ-менеджменту для формирования бюджета функции кибербезопасности; делаются отчеты о трендах киберпреступлений, релевантных для компании группах киберпреступников и о предлагаемых мерах и методах противодействия.
Операционный уровень, на котором технические подробности предоставляются ИТ/ИБ-руководителям и руководству SOC, включая данные о вредоносных кампаниях злоумышленников, мотивации атакующих, вероятных целях атак; на основании этой информации проводится изменение ИБ-архитектуры, перенастройка СЗИ, приобретаются новые инструменты для SOC.
Тактический уровень, на котором детальная информация о TTPs, методах и операциях атакующих в структурированном виде передается в SOC-центр для настройки правил корреляции, сенсоров и аналитических инструментов.
Интеграция продуктов и сервисов аналитики киберугроз в процессы и инструменты SOC дает следующие преимущества:
Позволяет выбирать и приоритизировать корректные контрмеры на основании релевантных киберугроз;
Повышает результативность и полноту действий по реагированию;
Снижает процент успешных кибератак, включая атаки APT-группировок;
Улучшает выявление киберугроз, что снижает время незаметного присутствия атакующих в инфраструктуре;
Повышает ситуационную осведомленность и знания о киберугрозах на основании формирования информативной и детальной отчетности;
Повышает видимость контекста и связи между инцидентами и влиянием на бизнес;
Повышает осведомленность коллег из других SOC путем обмена данными об опыте обработки киберугроз;
Повышает экономическую эффективность и оправданность работы SOC благодаря применению накапливаемым знаний о киберугрозах;
Повышает осведомленность о профиле угроз компании-заказчика и о возможных целях кибератак;
Дает понимание недостатков в киберзащите и мотивирует устранять их.
Эффективное применение аналитики киберугроз требует глубокого понимания деятельности, бизнес-процессов и активов компании-заказчика для профилирования групп потенциальных атакующих. Требуется понимание следующих аспектов:
Контекст: понимание того, кто и почему будет атаковать компанию, какие возможности есть у злоумышленников, какие последствия может иметь атака;
Анализ: понимание того, что и когда уже случилось, что происходит сейчас, какие сценарии атаки и TTPs используются;
Действия: понимание того, где сейчас наблюдается вредоносная активность и какая именно, какие контрмеры следует предпринять, как применить CTI в конкретных СЗИ (например, в системах SIEM, SOAR) для поиска, сдерживания, устранения угрозы.
Использование CTI будет результативным и эффективным в случае, если SOC обладает следующими знаниями:
Информация об атакующих: контекст, мотивы, планы, "почерк" атакующих, технические индикаторы (например, используемое ВПО, а также индикаторы компрометации - сокращенно IoCs, Indicators of Compromise), тренды и предыдущие успешные атаки злоумышленников, возможности атакующих (ресурсы, способности проводить скрытные и сложные кибероперации, примерная численность киберпреступной группировки), используемые ими инструменты, инфраструктуры, ресурсы;
Релевантность: понимание членами команды SOC особенностей компании-заказчика (бизнес-процессы, конкурентные преимущества, ценные активы, ключевые сотрудники, защищаемая информация, применимые законодательные требования), понимание выстроенных партнерских взаимоотношений с контрагентами, а также иные сведения, которые могут быть интересны атакующим и релевантны их целям;
Техническая среда: архитектура IT и OT-сетей, облачная и on-prem инфраструктура, состояние цифровых активов, данные об уязвимостях, профиль поведения пользователей, систем и сущностей, а также иная ИБ-релевантная техническая информация (предупреждения, журналы аудита, данные с конечных точек и сетевых устройств и т.д.).
Авторы публикации подчеркивают, что ключевым аспектом для предотвращения кибератак с использованием методов киберразведки будет понимание целей, мотивов, «почерка» киберпреступников, а также атрибутирования (сопоставления) киберугроз и конкретных инцидентов с определенными группами атакующих. Такие группы могут фигурировать в специализированных отчетах как APT-группировки (Advanced Persistent Threat, буквально «продвинутая постоянная угроза») с определенными порядковыми номерами (например, APT33 или APT41) или именами собственными (например, Darkhotel или Silence); со справочным перечнем этих групп можно ознакомиться на сайте проекта MITRE ATT&CK, там же содержится и описание основных этапов и TTPs современных киберпреступных групп. В целом, понимание того, какая именно группа вероятно готовится или уже производит кибератаку, позволяет предсказать дальнейшие шаги атакующих, а создание профиля киберугроз компании позволяет сузить круг потенциальных APT-групп, которые, с определенной долей вероятности, будут пытаться атаковать компанию, и, соответственно, лучше подготовиться к отражению таких атак, осуществляемых с помощью характерного для конкретной APT-группы инструментария. При этом точное атрибутирование кибератаки конкретной APT-группе может быть весьма ресурсозатратным и не всегда целесообразным, поэтому авторы предлагают использовать методы ассоциации злоумышленников - поиск вероятных связей между вредоносными действиями и возможными киберпреступными группами, что позволит установить взаимосвязи между атакующими и атрибутами атак (например, индикаторами компрометации, TTPs). Такой анализ позволит понять, какие вредоносные действия атакующие уже осуществили, могут осуществить в дальнейшем, а также их мотивацию и конечную цель атаки. Знаниями, которые получают CTI-аналитики в рамках своих исследований, следует в контролируемом виде обмениваться с родительскими, дочерними, партнерскими SOC-центрами и ИБ-подразделениями, докладывать заинтересованными руководителями компании-заказчика. При получении информации о готовящемся кибернападении важно будет подготовить не только защитные меры, но и использовать систему хостов-приманок для атакующих с целью более глубокого понимания их TTPs.
3. Использование инструментов аналитики киберугроз
При принятии решения о применении тех или иных CTI-инструментов, авторы публикации рекомендуют обратить внимание на следующие факторы:
Применимость в технологической составляющей SOC: выдает ил CTI-инструмент данные, применимые в инструментарии SOC и полезные для работы команды SOC?
Проверка качества данных: если CTI-инструмент выдает неточные данные, то должны быть инструменты настройки доверия получаемой информации;
Отслеживание происхождения CTI-данных: как изменяются CTI-данные, откуда они приходят, какие исходные данные использовались для формирования CTI-данных, надежен ли их источник?
Определите и поддерживайте правила атрибуции/ассоциации атакующих: заранее определите уровни вероятности и доверия при проведении атрибутирования или ассоциирования групп атакующих на основе CTI-данных;
Определите и поддерживайте правила мониторинга и реагирования: заранее договоритесь, когда можно ограничиться мониторингом активности, а когда следует выполнять действия по активному реагированию при выполнении предварительно разработанных условий.
Для работы с CTI прежде всего нужны квалифицированные, опытные эксперты-аналитики киберугроз, но для помощи им можно использовать технологические решения - такие, как TIP (Threat Intelligence Platform, платформа аналитики киберугроз). Системы TIP предназначены для обработки CTI-данных, т.е. для получения, упорядочивания, корреляции, использования больших объемов данных, относящихся к атакующим, включая индикаторы компрометации; TIP-решения также позволяют эффективно управлять знаниями о киберугрозах в компании. Наиболее эффективно TIP будет применяться в связке с технологическими инструментами SOC, которые позволяют проводить корреляцию, обогащение, совместную работу с CTI-данными, например, с системами SIEM и SOAR и с платформами обработки Big Data. Платформа TIP поможет ответить на вопросы о длительности присутствия атакующих в инфраструктуре, о характере выполненных ими действий, а также о происхождении CTI-данных и о CTI-отчетах с описанием похожей вредоносной активности.
При выборе TIP-решения следует обратить внимание на следующие характеристики платформы:
Платформа TIP должна позволять организовать совместную работу аналитиков киберугроз, а также трекинг обнаруженных артефактов, активности злоумышленников и их вредоносных кампаний;
Интеграционные возможности: TIP-решение должно корректно взаимодействовать с источниками CTI-данных (коммерческими и Open Source) и с инструментами SOC (SIEM, SOAR, Big Data);
TI-фиды «из коробки»: хорошая TIP должна по умолчанию предоставлять варианты интеграции и получения данных из нескольких источников CTI-данных, а также обеспечивать дедупликацию получаемых данных;
Обратная связь и скоринг: TIP-решение должно позволять проводить скоринг (оценку) получаемых CTI-данных на основании их качества и применимости, а также приоритизировать обработку CTI-данных в SOC на основании проведенной оценки;
Конфиденциальность: получаемые CTI-данные могут приходить их различных источников, а их обработка может быть ограничена требования конфиденциальности (например, с применением TLP-меток, от англ. Traffic Light Protocol) - эти обстоятельства требуется учитывать в TIP;
Ручной анализ: TIP-решение должно позволять аналитику киберугроз самостоятельно связывать признаки активности атакующих, проводить корреляцию, группировать сходные сущности;
Аудит и управление изменениями: TIP-система должна вести учет выполненных действий и откатывать изменения в случае внесения неверных данных или создания неточной ассоциации или атрибутирования;
Масштабируемость, производительность: TI-фиды могут содержать миллионы индикаторов компрометации, которые TIP-система должна оперативно обрабатывать.
4. Сложности и вызовы при работе с CTI-данными
Авторы публикации напоминают, что задача аналитики киберугроз стоит шире, чем простая обработка индикаторов компрометации (сигнатур, хэшей, IP-адресов и т.д.), которые могут быть легко изменены атакующими для обхода СЗИ; в киберразведке важно понимать TTPs злоумышленников, использовать индикаторы атак и контекстуализированную информацию при анализе. Указаны также некоторые типичные заблуждения, характерные при создании CTI-функции в SOC:
CTI-данные создаются по-разному: некоторые источники CTI используют общедоступные CTI-данные и переупаковывают их, добавляя свою аналитику, поэтому важно понимать происхождение и изначальные источники CTI-данных; также необходимо понимать, что именно подразумевается под CTI-данными в каждом конкретном случае (это могут быть и списки индикаторов компрометации, и неструктурированные отчеты о киберрасследованиях);
Слишком большой объем CTI-данных может создать информационный шум, а не принести пользу: важны применимость и результативность CTI-данных, а не их количество;
Не все CTI-данные полезны для всех SOC: при аналитике киберугроз следует фокусироваться на TTPs тех киберпреступных групп, которые, как правило, атакуют именно тот сектор экономики, в котором работает компания-заказчик услуг SOC;
Стоимость CTI-сервисов и данных не всегда важна: некоторые большие команды аналитиков киберугроз могут успешно использовать общедоступные CTI-данные и обмен информацией с партнерскими SOC-центрами, а некоторые небольшие SOC могут отдавать предпочтение коммерческим CTI-инструментам и фидам;
ВПО и CTI - это разные вещи: анализ киберугроз не должен фокусироваться на мониторинге использования ВПО злоумышленниками, т.к. зачастую при атаке используются легитимные утилиты и средства (техника "living off the land"); ВПО может использоваться на каки-то этапах атаки, но фокус CTI-аналитики должен быть на понимании целей и TTPs атакующих для корректного выстраивания защитных мер;
IoCs и CTI - это разные вещи: индикаторы компрометации могут дать некоторую «пищу для размышлений», но сами по себе не являются аналитикой киберугроз; важно, чтобы киберразведка давала ответы на вопросы лиц, принимающих решения, а также содержала применимый контекст.
Стратегия №7 «Выбирайте и собирайте правильные данные»
При анализе действий атакующих необходим целостный, стратегически выверенный подход к выбору и обработке данных, которые дадут максимально полную и точную картину кибератаки. Важны данные от сенсоров, журналы аудита, логи сетевых и хостовых систем, приложений, точек мониторинга вне зависимости от их местоположения - они составляют основную массу обрабатываемых в SOC данных. Стратегия №7 посвящена методике результативного и эффективного выбора и обработки правильных данных в разумных количествах из нужных источников.
1. Планирование сбора данных
На этапе планирования сбора данных важно выявить самый ценные источники и данные, чтобы не пропустить значимые события ИБ. При этом важно соблюсти баланс между сбором недостаточного количества данных, что может привести к неспособности обнаружить кибератаку, и сбором слишком большого количества данных в силу ресурсозатратности для аналитиков и технологических решений. Ценность обрабатываемых SOC данных находится на пике, когда данных достаточно для эффективного выявления кибератак, при этом это количество данных не перегружает персонал и технологии SOC. При планировании сбора данных важно понимать, какие задачи будет решены с помощью обработки выбранных данных; в сборе данных может быть заинтересован не только SOC, но и другие ИТ/ИБ-подразделения компании. Обработка ИБ-телеметрии может быть полезна для защиты информационных активов, систем, сетей, защиты от внутренних угроз, сбора цифровых улик, контроля производительности информационной инфраструктуры, выявления ошибок в работе систем, поиска корневых причин инцидентов, управления конфигурациями систем.
Данные, которые нужны SOC-центру, можно получать из различных источников; понимание функционирования таких источников является ключом к определению того, какие данные можно использовать для тех или иных сценариев обнаружения инцидентов (англ. "use cases"), и какие данные являются первоприоритетными. В Приложении "E" к публикации приведен список возможных источников ИБ-телеметрии (различные СЗИ, журналы ОС, сетевые устройства, инфраструктурные элементы) и их характеристики: тип передаваемой информации, ориентировочное количество событий в сутки, а также субъективная оценка полезности данных от различных источников.
При выборе источников и типа данных членам SOC-центра также следует ответить на следующие вопросы:
Как данные от специализированных ИБ-систем смогут дополнить информацию из журналов событий?
Каково качество и понятность формируемых логов: пригодны ли логи для анализа человеком или информационной системой, какова логическая связность создаваемых событий друг с другом, возможно ли настроить политики логирования для удовлетворения потребностей SOC?
Доступность и возможность обработки логов: пишутся ли логи в вендоро-нейтральном формате, можно ли их обрабатывать инструментами сбора журналов событий и в текущей SIEM-системе, каковы затраты на настройку парсинга и нормализации данных от источника, могут ли владельцы систем предоставить прямой доступ к журналам аудита своих систем, есть ли в инфраструктуре уже готовое решение для централизованной обработки логов (syslog-коллектор, шина сообщений, централизованное хранилище данных), каков будет общий объем собираемых логов, справится ли с нагрузкой аппаратное/программное обеспечение?
Охват системы журналирования: сможет ли выбранный источник данных охватить значительную часть инфраструктуры компании, сможет ли источник повысить качество мониторинга работы критичной системы?
При настройке мониторинга и сбора данных важно помнить об их возможном негативном влиянии на инфраструктуру компании; для минимизации негативного влияния авторы публикации дают следующие рекомендации:
Минимизируйте количество установленных агентов сбора логов, особенно на конечных системах;
Тщательно настройте параметры производительности агентов, такие как частота запросов, количество передаваемых в каждом запросе событий, потребление вычислительных ресурсов конечной точки;
Используйте существующие точки сбора информации (например, syslog-коллекторы и управляющие серверы), с учетом того, что данные передаются на эти точки сбора информации без потерь и задержек, у SIEM-системы есть агент для такой точки сбора, а данные с точки сбора передаются без задержек для возможности корреляции с другими релевантными событиями;
По возможности используйте гарантированную доставку: используйте протокол TCP вместо UDP, размещайте агенты сбора в логической/физической близости к источнику данных для минимизации задержек и более широкого применения методов шифрования передающихся данных, а также используйте технологии шины сообщений, такие как Apache Kafka, для обеспечения пакетной обработки, шифрования, сжатия данных;
Используйте SIEM-решение или Log Management систему, которые могут переносить данные с одного агента на множественные места хранения для обеспечения отказоустойчивости и непрерывности процессов мониторинга и сбора логов;
Старайтесь использовать стабильные и киберустойчивые системы сбора ИБ-телеметрии, анализируйте количество аварийных завершений их работы, устойчивость к атакам и к попыткам нарушения и вмешательства в их работу со стороны злоумышленников.
При планировании сбора данных следует заключить и задокументировать формальные внутренние договоренности о подключении источников, сборе данных и услугах мониторинга, которые оказывает SOC-центр. В таком документе следует указать контактные данные технических специалистов и руководителей, перечень собираемых данных, цель сбора данных (конкретные сценарии использования, типы киберугроз), список ответственных за хранение и предоставление журналов аудита по запросу, список контактных лиц для обращения в случае выхода источника их строя, а также меры, предпринимаемые для обеспечения безопасности собираемых данных (персональных данных, конфиденциальной информации), ссылки на релевантные внутренние нормативные документы и перечень систем, использующихся для сбора данных.
Также SOC-центру необходимо встроиться в процессы создания новых сервисов и систем в компании-заказчике с тем, чтобы требования по включению журналирования и пересылки логов выполнялись при создании или изменении элементов инфраструктуры, причем рекомендуется разработать и согласовать внутренние стандарты для выполнения указанных действий, а также стандартизировать развёртывание, обслуживание и затраты на мониторинг и сбор логов. Затраты на процессы сбора и обработки ИБ-телеметрии напрямую зависят от объема собираемых данных: различные СЗИ и ИТ/ИБ-системы могут передавать разное количество данных, которые могут использоваться при предотвращении кибератак, при выявлении инцидентов и при проведении анализа/форензики последствий инцидента, поэтому рекомендуется выбирать наиболее эффективные и результативные источники данных в конкретной инфраструктуре, которые при разумных затратах на их хранение и обработку смогут оказать наибольшую помощь SOC-центру.
Тонкая настройка (тюнинг) источников данных выполняется для достижения баланса между объемом данных и их пользой для выявления кибератак: при слишком грубой настройке можно или пропустить важные события ввиду недостаточности получаемой информации, или «засыпать» членов команды SOC нужными и ненужными данными, что также может привести к пропуску инцидента ввиду утомления от количества событий и предупреждений. В публикации рекомендуется сразу отфильтровать источники, которые предоставляют малоинформативные данные - это позволит отсеять «информационный шум» на первом этапе. В случае работы в распределенных инфраструктурах рекомендуется обрабатывать данные локально, т.е. ближе к источникам на соответствующих площадках, а анализировать - централизованно, что позволит распределить нагрузку. Кроме того, следует логировать не только события «отказа» (когда СЗИ блокируют активность или ИТ/ИБ-системы не разрешают выполнение запрашиваемых операций), но и события «успеха» (когда определенные действия была разрешены и выполнены), поскольку при расследовании важно понимать не только неудачные действия атакующих, но и операции, которые были ими выполнены. Авторы публикации также приводят три основных подхода к настройке источников данных, которые имеют свои плюсы и минусы:
Включение всех возможных опций и сбор всех возможных данных от всех источников с последующей «вычисткой» от неинформативных событий и отключением неэффективных опций журналирования;
Включение опций журналирования и обработка новых типов данных по мере необходимости с предварительным формулированием потребностей в мониторинге тех или иных типов событий и использовании определенных источников;
Использование имеющихся средств обработки данных, таких как промежуточные системы Log Management или платформы обработки Big Data, что позволяет обрабатывать ИБ-телеметрию ближе к источнику данных до заведения её в контур SOC.
В публикации подчеркивается важность контроля за функционированием источников данных, которые могут непрерывно появляться и исчезать вместе с вводом новых систем и отключением старых, особенно в больших инфраструктурах. Авторы публикации дают следующие рекомендации для управления процессом обслуживания сенсоров и источников данных:
Применяйте методы управления конфигурациями для контроля изменений настроек источников данных (например, контролируя перечень источников и лиц, ответственных за каждый источник);
Поддерживайте обмен информацией с системными администраторами и инженерным составом для контроля вносимых в инфраструктуру изменений и получения новостей о вводе новых систем в эксплуатацию;
Регулярно проверяйте статус источников данных - это можно делать ежедневно или при заступлении новой смены SOC-центра; кроме того, следует проверять корректность получаемых данных, особенно от критичных источников, а также включить охват источников данных и их работоспособность в систему метрик SOC;
Используйте встроенные средства оценки работоспособности сенсоров и источников данных, которые смогут предупредить об ошибках;
Старайтесь оперативно выявлять сбои в работе источников данных и немедленно обращайтесь к ответственным за систему, чтобы найти причину сбоя «по горячим следам».
В заключении раздела о планировании сбора данных авторы публикации напоминают о важности согласования сроков хранения собранных данных: период хранения может определяться внутренними требованиями компании-заказчика, законодательными нормами, а также риск-профилем компании-заказчика и бюджетными ограничениями. Как правило, период хранения данных устанавливается равным 12 или более месяцам, но в некоторых случаях может быть расширен. При этом важно обеспечить не только техническую возможность хранения информации (т.е. использовать вместительную дисковую подсистему), но и возможность оперативного поиска по собранным данным по всему объему информации.
Далее, в Стратегии №7 идет описание различных технологий защиты информации, которые могут предоставлять информацию SOC-центру для мониторинга и реагирования. Детальному описанию технологий можно посвятить отдельные большие публикации, поэтому далее приведем лишь краткое описание содержимого разделов Стратегии №7.
2. Средства обнаружения вторжений
Средства обнаружения вторжений могут быть разделены на следующие типы:
Системы на основе поведенческого анализа (включая выявление аномалий и машинное обучение) и на основе сигнатур (включая поиск соответствия индикаторам компрометации);
Сетевые и хостовые средства обнаружения вторжений;
Пассивный мониторинг (системы обнаружения вторжений - Intrusion Detection Systems, IDS) и активное предотвращение вторжений (системы предотвращения вторжений - Intrusion Prevention Systems, IPS).
3. Средства мониторинга и защиты конечных точек
Данные от конечных точек (серверов, рабочих станций), как правило, предоставляют более полную и целостную картину происходящего для выявления и подтверждения кибератак по сравнению с сетевыми средствами защиты. На конечных точках можно контролировать состояние файловых систем, ОЗУ, ЦПУ, подключенных устройств. Для продвинутого мониторинга и защиты можно использовать решения для защиты конечных точек (Endpoint Detection and Response, EDR), которые позволяют выявить вредоносную активность на основе анализа множества факторов, предоставляют расширенную ИБ-телеметрию, позволяют выполнить активные действия по реагированию. Решения для контроля запуска приложений запрещают или разрешают запуск процессов по модели разрешительных или запретительных списков, управление которыми требует значительных ресурсозатрат. Классические СЗИ, такие как антивирусы и хостовые фаирволлы, все еще могут использоваться для обеспечения кибербезопасности, но только в сочетании с другими технологиями при выстраивании эшелонированной системы киберзащиты.
Другими средствами, описанными в публикации, являются системы защиты от утечек данных (Data Loss Prevention, DLP) и системы мониторинга активности пользователей. При этом авторы публикации указывают на необходимость применения конкретных мер защиты в зависимости от критичности системы, привилегий работающих в ней пользователей, уязвимостей и поверхности атаки системы.
4. Средства сетевого мониторинга
Несмотря на снижение популярности средств сетевого мониторинга, в том числе из-за преобладания зашифрованного трафика, эти решения до сих пор могут быть использованы SOC-центром как один из самых простых и доступных вариантов. Важными характеристиками сетевых СЗИ будут: процент ложноположительных срабатываний, детали и контекст сработавших сигнатур, возможности по активному реагированию, пропускная способность и влияние на сетевую инфраструктуру, а также способы интеграции с другими технологиями и стоимость.
5. Облачные инфраструктуры
С ростом использования облачных технологий SOC должен брать на мониторинг облачные системы, сервисы, ресурсы. В облачных инфраструктурах можно применять многие подходы, использующиеся для защиты on-prem инфраструктур, при этом с учетом большой распределенности облачных сетей имеет смысл фокусироваться на мониторинге конкретных сервисов и конечных точек. Также следует быть готовым к работе с новыми типами источников данных и с незнакомыми ранее облачными технологиями защиты.
6. Инфраструктуры с нулевым доверием
В сценариях работы в сетях с нулевым доверием (англ. Zero Trust) можно использовать комбинацию различных продуктов для мониторинга: EDR - для конечных точек, DLP - для данных, контроль пользователей и ресурсов - для приложений.
7. OT-инфраструктуры
В OT-системах и сетях обеспечение доступности имеет больший приоритет, чем обеспечение конфиденциальности и целостности. Основными вызовами для защиты OT-инфраструктур могут стать проприетарные специфические протоколы взаимодействия, разнообразие вендоров и моделей, ограничения по установке и применению устройств, ограниченный выбор специализированных СЗИ для OT-инфраструктур. Особое внимание следует обращать на технологические стыки между IT и OT сетями, а также на взаимодействие с IoT-устройствами.