С чего мы начинали строить SOC'и
Эта история будет несколько личной - с одной из предыдущих команд, в которой я когда-то была просто инженером, много лет назад мы начинали строить SOC для заказчиков, не сильно-то и понимая, как это делать правильно.
В ход шло все - международные стандарты, здравый смысл и желание «сделать хорошо». В итоге, оглядываясь назад, мы видим, что то, какими стали центры сейчас и какими они были тогда - очевидно, очень разные вещи. Но и то, каким стал SOC, собранный нами за 1-2 года, поразительно отличалось от всего, что было в самом начале - от идеологии до непосредственно исполнения.
Несколько раз в каждом из проектов перерабатывался самый каркас - типы инцидентов, плейбуки, команды аналитиков. Менялись роли, классификация, сам подход к тому, как расследовать инциденты.
Изначально мы закладывали в каждый проект разработку по спирали, метод «Сделал? переделай» для каждого звена этой цепи. То есть, неотъемлемой частью любого плейбука был шаг «Посмотри ретроспективно на все шаги и реши, как это поменять для дальнейшей работы». В целом, если изначально закладывать плейбук как набор определенных шагов, можно итерационно улучшать их в комфортном ритме, но смена самой концепции на ходу - это сложно, дорого (хотя бы по времени) и, самое главное, это не дает никакой отдачи от проекта, не говоря уже о том, что каждый шаг должен документироваться. Вот вроде бы и сделал что-то, но этот вариант никогда не конечный, никогда не самый лучший и на самом деле иногда даже не факт, что рабочий.
Мы разрывались между тем, чтобы помочь наладить процессы, и тем, чтобы закрыть проект и выполнить свои обязательства перед заказчиком, и на самом деле редко бывают случаи, когда два эти понятия означают одно и то же. Баланс между тем, чтобы удержаться в рамках сроков, тем, чтобы команда не выгорела и смогла вытянуть несколько проектов сразу, и тем, чтобы результат был хорошим, редко достижим, особенно с первого раза.
В итоге в какой-то момент результат был признан конечным, но на самом деле все только начиналось.
Как все крутые идеи находили себе место
Нередко в процессе разработки (или построения) в голову нескольким людям может прийти бессчётное количество новаторских и хороших идей; жаль, что не всегда есть ресурсы для проверки этих гипотез.
И жаль, когда принимающая сторона не загорается этими идеями, что в целом можно понять, когда работаешь с командой, которая хватается за все подряд в поисках идеального варианта. На самом деле, что-то щелкает, когда все сделано правильно - смотришь на результат своей работы и не хочешь ничего менять, потому что все сделано к месту и хорошо. Наибольшую отдачу мы получали, работая с визуализацией и метриками эффективности: когда начинаешь взаимодействовать с людьми из SOC-команды, понимаешь их боли и потребности и на время занимаешь их место, становится гораздо проще понять, что конкретно тебе хотелось бы видеть на данный момент. В дальнейшем в Security Vision это перетекло в идею полноценных персональных личных кабинетов как для заказчика, так и для отдельных аналитиков - и каждый элемент подбирался на основе нашего персонального опыта построения SOC или работы в нем. То есть инструментарий на самом деле не берется из ниоткуда и не списывается из разнообразных постановлений и приказов - в основном это опыт.
Очень много вещей пришлось отложить из-за недостатка времени, но некоторые из них дождались своего часа через годы - например, наше желание не зацикливаться на захардкоженном плейбуке и создавать что-то динамическое в режиме реального времени :)
Сколько раз мы все переделывали
тогда
Честно говоря, очень много. Сколько раз мы начинали с нуля, вот так точнее было бы сказать. Сколько раз строили - столько и начинали. Но на самом деле, кроме шуток, так все и было. И каждый раз, приходя к новому заказчику и начиная «делать SOC», мы раз за разом пытались нащупать ту самую «формулу успеха». Это сейчас SOC, в том числе коммерческий и в том числе SOCaaS, достаточно распространен и оброс своими гласными и негласными стандартами, но тогда, 8 лет назад, это было сложно.
Помогал ли опыт зарубежных коллег? Частично да. Но в итоге, поработав немного в международной компании, от себя лично могу сказать, что процессы очень сильно разнятся - от выбора инструментария до подхода к созданию workflow. Это все идет сверху вниз, от бизнеса к ИБ, и разные потребности требуют разной реализации.
и сейчас
Сейчас вся наша команда Security Vision, частью которой являюсь и я, разрабатывает готовые коробочные решения под внутренние процессы. И сколько раз мы прорабатывали гипотезу и концепцию одной коробки все вместе - не счесть.
Иногда забавно на ретроспективе сравнить до и после, положа рядом план процессов в самом начале и итоговый вариант, уже демонстрируемый заказчику - чаще всего разница велика, а изменения касаются самых разнообразных частей продукта.
К примеру, мы несколько раз прорабатывали, как именно оптимально понятным образом реализовать в системе действия по реагированию, и пришли в итоге к объектно-ориентированному подходу - почти такому же, который несколько лет был у одного зарубежного вендора (да не такому), но который не взлетал из-за специфики работы аналитиков у нас.
Почему возникают переделки?
гипотезы
Мы всегда придумываем что-то новое. Всегда хочется найти silver bullet для всего - уникальное, ни на что не похожее, новое - и сделать это первыми. Это касается как проблем с UI/UX, банально плейбуков, рабочих мест, так и в целом глобального подхода что к инцидентам, что к активам - иногда отработка гипотезы требует вмешательства в соседние с ИБ процессы, работу с тем же ИТ-департаментом и бизнесом.
Гипотезы возникают как из опыта, так и из смежных сфер - например, из BI мы подчерпнули ставший традиционным подход к планированию и настройке дашбордов, а из каких-то открытых инструментов сообщества - вектор, по которому стали выстраивать экспертизу.
экспертиза
Аналитики не стоят на месте. Технологии позволяют все больше и больше автоматизировать рутинные задачи, освобождая время для чего-то нестандартного. Тогда перед нами возникает еще и задача стандартизировать это и автоматизировать снова и снова.
То, что раньше казалось ручным трудом и набором сложных правил - та же классификация - теперь обретает свою реализацию в динамическом исполнении, иногда даже с применением ML.
Возросший уровень экспертизы диктует и иную планку требований к продукту - к примеру, раньше за хороший результат считалась просто сама возможность взять и написать в системе коннектор, потом - наличие маркетплейса и набора коннекторов хоть где-то, а сейчас - преднастроенная библиотека работающих из коробки интеграций.
изменчивый мир
Другие производители и специалисты тоже не стоят на месте - помимо технических подходов к управлению инцидентами, возникает все больше и больше новых best practice расследования в принципе - куда теперь смотрят для поиска улик, как взаимодействуют с тем же TI для получения полной картины и маркеров злоумышленника в казалось бы простой истории. Не только появляются новые классы решений, с которыми требуется интеграция, но и логика вкупе с экспертизой, заложенная в них, дает больше простора.
тренды
К примеру, работа с сетевой форензикой и новый инструментарий.
Новые методы злоумышленников для получения информации, которые теперь классифицируются иначе, чем раньше.
Не говоря уже об AI, который используется по обе стороны баррикад.
Как сделать хорошо?
Самое главное - это понимать, что с первого раза сделать что-то идеально не получится никогда.
оптимизация
Оптимизируются как процессы, так и конечные детали решения - будь то работа конкретного коннектора или даже алгоритма заполнения таблицы с данными на карточке инцидента.
Цепочка шагов, которой пользуется аналитик при расследовании, должна каждый раз рассматриваться в разрезе того числа попыток, которые человек предпринимает внутри одного алгоритма: что-то избыточно, чего-то недостает раз за разом, и именно это и нужно менять; объединять и сокращать все, что позволит достигать цели быстрее и понятнее.
слышать потребности заказчика
Иногда не стоит переделывать что-то уже устоявшееся только потому, что это не оптимально. Привычка может работать эффективнее нововведений даже вдолгую.
И, с другой стороны, никогда не стоит отметать новые идеи, даже если лично вам они кажутся несостоятельными или просто глупыми. По факту апробации на первый взгляд безобидное желание передвинуть кнопку или реализовать коммуникацию другим способом могут существенно ускорить процесс работы.
больше автоматизации
Но только в том случае, если это эффективнее ручного труда с течением времени.
Не стоит автоматизировать абсолютно все подряд, без четкого плана и какого-либо проверенного алгоритма реализации. Иногда в зоне экспертизы автоматизация (пока) невозможна, а время можно потратить на что-нибудь еще.
Тем не менее, говоря о тех же тенденциях и трендах, можно сделать выводы о том, что любое привычное действие аналитика должно превращаться хотя бы в кнопку, а не блуждание в лабиринтах другой системы.
регулярно пересматривать процесс
И речь здесь идет не только о конкретном плейбуке, но и о процессе управления инцидентами в целом.
Как люди общаются, как менеджер принимает и оценивает работу - это все также требует регулярного пересмотра, помимо технических настроек. Иногда коммуникации гораздо важнее подкапотного движка, а понятная система вознаграждений (привет, геймификация!) мотивирует куда лучше сухих цифр на дашборде.
Нельзя одновременно получить хороший и шустрый механизм разбора инцидентов, если у вас под слоем пыли лежит неприкасаемый бумажный том с распечатками блок-схем.
Трактовка LL в контексте инцидента
На самом деле вся эта статья могла быть только об этом.
Какой он, тот самый последний шаг, последняя фаза NIST и удручающая некоторых необходимость вернуться к самому началу? Традиционно работа над ошибками - это работа аналитика, зачастую аналитик L3 совмещает в себе как расследование, так и этот непростой процесс.
Мы работаем над тем, чтобы отдать этот процесс на откуп автоматизации (и даже были попытки), но пока человеку требуется, посмотрев на результат своих трудов и взяв, к примеру, несколько сотен тем или иным образом закрытых инцидентов одного типа, решить, в какой момент ему чего-то не хватало или что было лишним. Во что упиралось каждый раз расследование и теряло в скорости, наполнении. Какие-то изменения можно было бы применить сразу же, а какие-то потребуют времени и переработки целой концепции. Рассмотрим подробнее:
правила
Наверное, это самая большая проблема и боль - правильно настроить сбор событий и их корреляцию. Правильно их оптимизировать - огромная задача даже не на один год, а большинство SOC пользуется сложными многоуровневыми правилами, конструкциями «если не было» помимо «если было» и прочая. Дело не только в обработке false positive, хотя и в этом тоже, а еще и в том, как правильно применить результат расследований - возможно, было бы полезно поменять логику, подход и агрегацию правил, изменить что-то в настройке получения событий от источника.
Правила не всегда ведут в false из всех возможных проблем, это может влиять на производительность и вероятность получения ожидаемого результата. Сколько раз для нашего первого SOC мы переписывали правила - не счесть: адаптация под особенности инфраструктуры, под другие связанные процессы в компании (например, управление политиками), возможность получить то же самое, но быстрее, и тому подобное.
инфраструктура
Это настоящий ночной кошмар сокостроителя - сделать все близко к идеальному, подружить ИТ и ИБ команды, оттестировать все интеграции и столкнуться с тем, что привычная схема с огромным трудом масштабируется, когда у заказчика происходят внутренние перестройки инфраструктуры. Когда одно СЗИ заменяется на другое, но несколько иным принципом работы, когда сетевые сегменты разъезжаются кто куда и теперь старые кнопки, подходы, коммуникации - все не работает.
И с другой стороны, без этого никогда не получится, потому что постинцидентный этап и харденинг как раз содержат в себе необходимость эту инфраструктуру менять, конфигурировать иначе и защищать надежнее.
После расследованного инцидента, а особенно реального, изменения могут быть достаточно драматичными, вплоть до того, что заказчик может взяться за разработку самостоятельного решения по детекту.
плейбуки
То, что претерпевало изменения регулярно.
Сначала - на бумаге, когда до реальной системы было еще далеко, и процессы в компании только-только выстраивались. Тогда менялась и логика работы, и сам подход к описанию - то это были UML-диаграммы с акторами, то мы использовали BPMN-нотацию (как некоторые вендоры), иногда в ход шел просто текст с нумерацией, и неосведомленный человек, заглянувший в такой документ, могу бы подумать, что речь идет о странной ролевой игре - если тебе попался вирус, открой страницу 211 - что-то было в этом от мира игр.
После - уже в самой системе, когда все необходимые вехи были определены (какие работают политики, где пролегают области компетенций), наступал момент тестирования, в ходе которого и отсекались гипотезы, и специально необученные люди были вынуждены проходить все этапы подобно аналитику (так мы понимали, насколько продукт доступен человеку без опыта, потому что к исходу тестов глаз замыливался).
Когда и это было позади, финальный вариант отдавался людям обученным, и мы следили за аналитиками - что они ищут, куда смотрят, - чтобы лучше настроить визуал и сделать его удобнее.
И, наконец, мы пересматривали плоды наших трудов после окончания работы, чтобы убедиться в том, что все (или почти все) было сделано не так.
Выводы
Очень много копий было сломано на этом пути.
То, что сейчас представляет собой российский SOC в вакууме - это стек технологий и опыт многих аналитических команд, которые временем и упорством вывели некий стандарт процесса управления инцидентами.
Под этот стандарт пытаются подстроиться решения и продукты, чтобы нагнать опыт и открыть дорогу чему-то большему. Главное помнить, что переделывать - не стыдно и не грустно, это очень важный шаг к развитию и разработке чего-то поистине полезного.
