Когда-то деревья были большими, а Solar JSOC – маленьким. Всех его сотрудников можно было пересчитать по пальцам двух рук и ног, поэтому вопроса о единых правилах игры не стояло. При небольшом тогда числе заказчиков мы и так прекрасно учитывали их разнообразные хотелки по выявлению инцидентов и оповещению (в этой компании к инфраструктуре могут удаленно подключаться подрядчики, а в той – по ночам работает админ Вася и это легитимно; здесь ждут мгновенных сообщений о любых подозрениях на инцидент, а там готовы повременить – главное максимум аналитики и т.д. и т.п.). Но со временем клиентов заметно прибавилось, ожидания от SOC у всех были разными (а обещания сейлов о кастомизации сервиса – щедрыми). И все это наряду с ростом числа собственных специалистов с их различающимся пониманием «прекрасного». Чтобы упорядочить возникшую энтропию, можно было, конечно, продолжать плодить инструкции по каждому поводу, а всех инженеров первой линии и аналитиков отправить на курсы развития сверхпамяти, но это чревато…Поэтому мы придумали более действенную схему работы.
Начнем с первой линии. Проблема в том, что буквально у каждого заказчика есть свои требования к процессам оповещения (что вполне нормально). Но когда этих заказчиков уже не 5 и не 10, а 100, просто невозможно разложить вокруг каждого инженера 100 инструкций.
Мы бы, может, даже и разложили их, если бы не одно «но», а именно – наша уверенность в том, что инструкции не работают. Нет, конечно, они работают, если они понятны и удобны. И можно легко написать подобные инструкции, просто запротоколировав текущую деятельность as is. Так во многих странах делают тропинки для пешеходов – просто укладывают брусчатку или асфальт там, где люди уже протоптали свои тропинки.
Сложнее в ситуации, когда надо инструкцией убедить людей перестать ходить там, где им удобно. Вполне возможно, это сработает у педантичных немцев или старательных японцев, но у нас… За все время коллеги только из одной организации сказали, что у них инструкции работают железно – безотносительно их удобства/полезности для исполнителя. На вопрос: «В чем секрет?» – ответ был простой: «Нам повезло – у нас есть дисбат».
Что же остается коммерческим предприятиям, которые желают добиться выполнения инструкций линейными исполнителями и при этом остаться в рамках правового поля(пытки у нас пока законом запрещены)? Для нас ответ один: либо сделать так, чтобы инструкцию технически нельзя было нарушить (в аналогии с тропинкой – копаем глубокий ров и запускаем туда аллигатора), либо делаем альтернативную тропинку более удобной (наводим чистоту, клумбы, скамейки, в жару ставим киоск с холодным пивом). Если есть возможность обеспечить тотальный контроль нарушения какой-либо инструкции – тоже вариант, но работает только тогда, когда по 100% нарушений следует свое наказание, иначе так и будут пытаться проскочить на авось.
Если ни один вариант не подходит, и инструкция остается просто инструкцией… Тогда можно снабдить её функцией «автопробуждения» в нужный момент. Не исполнитель должен вспоминать, что на этот случай где-то была инструкция, а случай должен размахивать перед ним флагом – «я особенный, инструкция по работе со мной прилагается».
Через эти фильтры мы и проводим все нововведения и изменения. В итоге сформировалось несколько основных инструментов, которые решают 99% всех задач – на удивление, их не так много:
1. Автоматически применяемый профиль уведомления. При заведении тикета с подозрением на инцидент происходит автозаполнение адресатов уведомления на стороне заказчика с учетом не только ключевых метаданных инцидента, но и его типа и критичности, времени суток и дня недели. Этим же механизмом можно переопределить критичность инцидента, SLA и приоритет обработки. Инженер просто расследует инцидент, заполняет шаблон уведомления и нажимает «send». Нет необходимости задумываться о том, каким адресатам он должен его разослать.
2. Шкала с весом подозрения на инцидент. В тикет-системе на основании множества параметров формируется «вес» инцидента, то есть его реальная значимость. Дело в том, что по договору критичность инцидента определяется только по его типу. Таким образом, подозрение на компрометацию учетной записи (УЗ) админа и обычного пользователя по договору и SLA имеют одинаковую критичность, но очевидно, что в реальности это не так. Такая же история, если инцидент произошел в критичном сетевом сегменте или тестовой зоне. Чтобы избежать разночтений в определении критичности инцидентов и необоснованных претензий в сторону инженеров, мы ввели простое правило: инциденты разбираются из очереди, начиная с самых «тяжелых» по «весу».
3. Автоподсчет реального времени, потраченного на расследование инцидента. Это мегаполезная статистика, применяемая нами как для множества механизмов автоматизации, так и для сверки заложенных в контракт и реальных затрат ресурсов.
4. Различные «защиты от дурака». Не самая светлая страница в жизни SOC с большим количеством клиентов. Не самая светлая, поскольку появились эти защиты не превентивно, а на собственном печальном опыте, когда в пылу большой нагрузки инженеры ошибались и допускали нарушение конфиденциальности. Например, заполняли профиль информацией, выгруженной из SIEM другого заказчика (в наших реалиях количество консолей SIEM давно исчисляется десятками и у каждого второго заказчика есть пользователь с учеткой “ivanov” и адресацией 172.20…); строили репорты на мультитенантной коре SIEM без признака заказчика либо написав шаблон, под который попали несколько заказчиков.
На больших объемах человеческий фактор будет проявлять себя в самых изощренных формах. Мы просто стараемся предупредить повторение того, с чем уже столкнулись. Поэтому сейчас уведомления просматриваются парсерами, которые ищут всевозможные отклонения: упоминание в тикете одного заказчика слов, характерных для другого заказчика; разночтения в адресатах уведомления и самом уведомлении; отсутствие поля с именованием заказчика в выгрузках или же упоминание в этом поле нескольких заказчиков и различные другие проверки.
5. Все прочие инструкции, как то: инструкция по расследованию инцидента данного типа, признаки ложных срабатываний, особенности обработки данного инцидента у конкретного заказчика или, например, напоминание о необходимости сопроводить данный инцидент в ночное время звонком – автоматически подклеиваются непосредственно к тикету, в рамках которого расследуется инцидент (о необходимости звонить ночью напомнят тоже только ночью ;). Таким образом, если у данного конкретного тикета есть какие-то отклонения от общего шаблона обработки, информация об этом обязана быть непосредственно в тикете.
И вот уже в том случае, когда вы как владелец процесса сделали все, чтобы обеспечить его выполнение, когда сработала вся необходимая автоматизация, когда сработали «защиты от дурака», а инструкции махали красными флагами в тикете, но инженер все равно прохлопал ушами или сознательно проигнорировал, – допускается заменить понятие «человеческий фактор» понятием «раззвездяйство»и забыть про недопустимость пыток в правовом поле – любой вменяемый судья поймет и признает, что вы действовали в состоянии аффекта, и оправдает.
Когда-то в этом поле было всего два, но очень сильных воина. Но было очевидно, что их ресурсов мало и расширение неизбежно. Постепенно появлялись новые сотрудники, в задачи которых входила реализация новых сценариев детектирования угроз, и мы столкнулись с проблемой «новой метлы»: у ребят было своё видение того, как нужно писать правила корреляции, каким образом работать с исключениями и т.д. В итоге появлялся разношерстный контент, разной степени зрелости, оптимальности кода и стабильности работы.
Всё это проявилось чуть позже — с увеличением количества заказчиков, масштабов их инфраструктуры и, как следствие, ростом нагрузки на SIEM: у нас начались проблемы с работоспособностью контента и самой SIEM. Назрела необходимость сформировать единые правила игры и описать наш подход к разработке сценариев: best practice – что делать можно, а чего нельзя, как мы реализуем типовые детекты, как пишутся профилирующие правила, работающие на большом потоке событий и т.д.
В идеальной картине мира, к которой мы стремились, созданный сценарий никак не зависит от того, чьими руками он собирался. Это было непросто, но с задачей мы справились: методология разработки контента для обеих SIEM описана в Confluence, и все новые сотрудники, в задачи которых входит разработка контента, изучают её в обязательном порядке. Ну а векторы развития этой методологии задают ведущие аналитики по работе с каждой из платформ.
По мере роста числа заказчиков и инсталляций SIEM возникла потребность в централизованном управлении контентом. Условно – при корректировке существующего сценария нам нужно быстро и просто применить исправление на всех SIEM. Разумеется, на этом пути мы столкнулись со множеством технических трудностей в части синхронизации контента, но это скорее тема для отдельной статьи.
Помимо техники, обозначилась еще одна важная проблема, связанная с кастомизацией сервиса. Аналитики по запросам заказчиков вносили доработки в сценарии (например, исключали из них какую-либо легитимную активность) – в такой ситуации ни о какой централизованной автосинхронизации не могло быть и речи, так как при первом же её запуске все доработки были бы перетёрты.
Эта проблема также была решена за счет формализации и описания методологии разработки, о которой написано выше. Исключения перенесли в специальные активные листы и табличные списки, содержимое которых не синхронизируется между инсталляциями, ввели использование pre-persistence правил и правил обогащения для учета нюансов инфраструктур заказчиков и т.д. Для хранения эталонного контента была введена master-инсталляция SIEM, ну а вся разработка производится на dev-стенде, на который не страшно пускать даже «зеленых» новичков с горящими глазами и пока еще без набитых шишек.
Чтобы избежать дублирования, пересечения или нерациональности разрабатываемых сценариев, была введена процедура так называемого пре-аппрува. Если аналитик хочет разработать новое правило выявления той или иной угрозы, предварительно он пишет письмо на группу более опытных коллег, в котором описывает цель сценария, логику его работы и предлагаемый способ реализации. После дискуссии разной степени длительности и накала страстей инициатор получает аппрув на разработку, с корректировками или же без них. Опять же этот процесс позволяет придерживаться единого подхода к разработке вплоть до правил именования сценариев. Да-да, это тоже важно для зрелого SOC!
По мере дальнейшего роста SOC неизбежно будут возникать всё новые «островки неопределенности», но мы теперь точно знаем: кажущийся хаос вполне можно упорядочить.
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
Конвейер и работающие инструкции
Начнем с первой линии. Проблема в том, что буквально у каждого заказчика есть свои требования к процессам оповещения (что вполне нормально). Но когда этих заказчиков уже не 5 и не 10, а 100, просто невозможно разложить вокруг каждого инженера 100 инструкций.
Мы бы, может, даже и разложили их, если бы не одно «но», а именно – наша уверенность в том, что инструкции не работают. Нет, конечно, они работают, если они понятны и удобны. И можно легко написать подобные инструкции, просто запротоколировав текущую деятельность as is. Так во многих странах делают тропинки для пешеходов – просто укладывают брусчатку или асфальт там, где люди уже протоптали свои тропинки.
Сложнее в ситуации, когда надо инструкцией убедить людей перестать ходить там, где им удобно. Вполне возможно, это сработает у педантичных немцев или старательных японцев, но у нас… За все время коллеги только из одной организации сказали, что у них инструкции работают железно – безотносительно их удобства/полезности для исполнителя. На вопрос: «В чем секрет?» – ответ был простой: «Нам повезло – у нас есть дисбат».
Что же остается коммерческим предприятиям, которые желают добиться выполнения инструкций линейными исполнителями и при этом остаться в рамках правового поля
Если ни один вариант не подходит, и инструкция остается просто инструкцией… Тогда можно снабдить её функцией «автопробуждения» в нужный момент. Не исполнитель должен вспоминать, что на этот случай где-то была инструкция, а случай должен размахивать перед ним флагом – «я особенный, инструкция по работе со мной прилагается».
Через эти фильтры мы и проводим все нововведения и изменения. В итоге сформировалось несколько основных инструментов, которые решают 99% всех задач – на удивление, их не так много:
1. Автоматически применяемый профиль уведомления. При заведении тикета с подозрением на инцидент происходит автозаполнение адресатов уведомления на стороне заказчика с учетом не только ключевых метаданных инцидента, но и его типа и критичности, времени суток и дня недели. Этим же механизмом можно переопределить критичность инцидента, SLA и приоритет обработки. Инженер просто расследует инцидент, заполняет шаблон уведомления и нажимает «send». Нет необходимости задумываться о том, каким адресатам он должен его разослать.
2. Шкала с весом подозрения на инцидент. В тикет-системе на основании множества параметров формируется «вес» инцидента, то есть его реальная значимость. Дело в том, что по договору критичность инцидента определяется только по его типу. Таким образом, подозрение на компрометацию учетной записи (УЗ) админа и обычного пользователя по договору и SLA имеют одинаковую критичность, но очевидно, что в реальности это не так. Такая же история, если инцидент произошел в критичном сетевом сегменте или тестовой зоне. Чтобы избежать разночтений в определении критичности инцидентов и необоснованных претензий в сторону инженеров, мы ввели простое правило: инциденты разбираются из очереди, начиная с самых «тяжелых» по «весу».
3. Автоподсчет реального времени, потраченного на расследование инцидента. Это мегаполезная статистика, применяемая нами как для множества механизмов автоматизации, так и для сверки заложенных в контракт и реальных затрат ресурсов.
4. Различные «защиты от дурака». Не самая светлая страница в жизни SOC с большим количеством клиентов. Не самая светлая, поскольку появились эти защиты не превентивно, а на собственном печальном опыте, когда в пылу большой нагрузки инженеры ошибались и допускали нарушение конфиденциальности. Например, заполняли профиль информацией, выгруженной из SIEM другого заказчика (в наших реалиях количество консолей SIEM давно исчисляется десятками и у каждого второго заказчика есть пользователь с учеткой “ivanov” и адресацией 172.20…); строили репорты на мультитенантной коре SIEM без признака заказчика либо написав шаблон, под который попали несколько заказчиков.
На больших объемах человеческий фактор будет проявлять себя в самых изощренных формах. Мы просто стараемся предупредить повторение того, с чем уже столкнулись. Поэтому сейчас уведомления просматриваются парсерами, которые ищут всевозможные отклонения: упоминание в тикете одного заказчика слов, характерных для другого заказчика; разночтения в адресатах уведомления и самом уведомлении; отсутствие поля с именованием заказчика в выгрузках или же упоминание в этом поле нескольких заказчиков и различные другие проверки.
5. Все прочие инструкции, как то: инструкция по расследованию инцидента данного типа, признаки ложных срабатываний, особенности обработки данного инцидента у конкретного заказчика или, например, напоминание о необходимости сопроводить данный инцидент в ночное время звонком – автоматически подклеиваются непосредственно к тикету, в рамках которого расследуется инцидент (о необходимости звонить ночью напомнят тоже только ночью ;). Таким образом, если у данного конкретного тикета есть какие-то отклонения от общего шаблона обработки, информация об этом обязана быть непосредственно в тикете.
И вот уже в том случае, когда вы как владелец процесса сделали все, чтобы обеспечить его выполнение, когда сработала вся необходимая автоматизация, когда сработали «защиты от дурака», а инструкции махали красными флагами в тикете, но инженер все равно прохлопал ушами или сознательно проигнорировал, – допускается заменить понятие «человеческий фактор» понятием «раззвездяйство»
Разработка контента
Когда-то в этом поле было всего два, но очень сильных воина. Но было очевидно, что их ресурсов мало и расширение неизбежно. Постепенно появлялись новые сотрудники, в задачи которых входила реализация новых сценариев детектирования угроз, и мы столкнулись с проблемой «новой метлы»: у ребят было своё видение того, как нужно писать правила корреляции, каким образом работать с исключениями и т.д. В итоге появлялся разношерстный контент, разной степени зрелости, оптимальности кода и стабильности работы.
Всё это проявилось чуть позже — с увеличением количества заказчиков, масштабов их инфраструктуры и, как следствие, ростом нагрузки на SIEM: у нас начались проблемы с работоспособностью контента и самой SIEM. Назрела необходимость сформировать единые правила игры и описать наш подход к разработке сценариев: best practice – что делать можно, а чего нельзя, как мы реализуем типовые детекты, как пишутся профилирующие правила, работающие на большом потоке событий и т.д.
В идеальной картине мира, к которой мы стремились, созданный сценарий никак не зависит от того, чьими руками он собирался. Это было непросто, но с задачей мы справились: методология разработки контента для обеих SIEM описана в Confluence, и все новые сотрудники, в задачи которых входит разработка контента, изучают её в обязательном порядке. Ну а векторы развития этой методологии задают ведущие аналитики по работе с каждой из платформ.
По мере роста числа заказчиков и инсталляций SIEM возникла потребность в централизованном управлении контентом. Условно – при корректировке существующего сценария нам нужно быстро и просто применить исправление на всех SIEM. Разумеется, на этом пути мы столкнулись со множеством технических трудностей в части синхронизации контента, но это скорее тема для отдельной статьи.
Помимо техники, обозначилась еще одна важная проблема, связанная с кастомизацией сервиса. Аналитики по запросам заказчиков вносили доработки в сценарии (например, исключали из них какую-либо легитимную активность) – в такой ситуации ни о какой централизованной автосинхронизации не могло быть и речи, так как при первом же её запуске все доработки были бы перетёрты.
Эта проблема также была решена за счет формализации и описания методологии разработки, о которой написано выше. Исключения перенесли в специальные активные листы и табличные списки, содержимое которых не синхронизируется между инсталляциями, ввели использование pre-persistence правил и правил обогащения для учета нюансов инфраструктур заказчиков и т.д. Для хранения эталонного контента была введена master-инсталляция SIEM, ну а вся разработка производится на dev-стенде, на который не страшно пускать даже «зеленых» новичков с горящими глазами и пока еще без набитых шишек.
Чтобы избежать дублирования, пересечения или нерациональности разрабатываемых сценариев, была введена процедура так называемого пре-аппрува. Если аналитик хочет разработать новое правило выявления той или иной угрозы, предварительно он пишет письмо на группу более опытных коллег, в котором описывает цель сценария, логику его работы и предлагаемый способ реализации. После дискуссии разной степени длительности и накала страстей инициатор получает аппрув на разработку, с корректировками или же без них. Опять же этот процесс позволяет придерживаться единого подхода к разработке вплоть до правил именования сценариев. Да-да, это тоже важно для зрелого SOC!
По мере дальнейшего роста SOC неизбежно будут возникать всё новые «островки неопределенности», но мы теперь точно знаем: кажущийся хаос вполне можно упорядочить.
Алексей Кривоногов, заместитель директора Solar JSOC по развитию региональной сети
