[Информационная безопасность] Проблемы роста SOC: как учесть +100500 хотелок заказчиков и не сойти с ума
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Когда-то деревья были большими, а 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 по развитию региональной сети
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность] (не) Безопасный дайджест: саботаж на Tesla, больничный вымогатель и «продавец душ»
- [Информационная безопасность, IT-инфраструктура] Зачем нужны сертифицированные средства защиты информации?
- [Спам и антиспам, Информационная безопасность, Accessibility, Браузеры, Фриланс] Сломался сайт или вас забанили?
- [Информационная безопасность] Google Project Zero раскрыл 0-day уязвимость в Windows
- [Информационная безопасность, Законодательство в IT] Россиянин получил 8 лет тюрьмы в США за создание бот-сети на $100 млн
- [Информационная безопасность, Python, Программирование] Побег из песочницы с Python (перевод)
- [Информационная безопасность] Security Week 45: тандем уязвимостей в Windows 10 и Chrome
- [Информационная безопасность, Биографии гиков] Сноуден решил получить российское гражданство
- [Информационная безопасность, IT-стандарты, Промышленное программирование, SCADA] Assurance Case: аргументированное обоснование безопасности
- [Информационная безопасность, Законодательство в IT] Где вводят официальные рекомендации для защиты домашнего Wi-Fi — инициативы Сингапура и ЕС
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_security, #_tier_1, #_tier_2, #_tier_3, #_tier_4, #_soc, #_intsidenty_ib (инциденты иб), #_tiketsistema (тикет-система), #_siem, #_blog_kompanii_rostelekomsolar (
Блог компании Ростелеком-Солар
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:57
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Когда-то деревья были большими, а 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 по развитию региональной сети =========== Источник: habr.com =========== Похожие новости:
Блог компании Ростелеком-Солар ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:57
Часовой пояс: UTC + 5