Comments 4
По ходу чтения возникло много вопросов, в какой-то момент перестал записывать.
ELK для LM — такое себе решение. Да, многое умеет «из коробки», но отсутствие агрегации и крайне тяжкий кросс-индексный поиск — это проблема. Со вторым еще можно жить, а вот требования к хранилищу будут очень жесткие.
Точно знаете, что такое threat hunting? А гипотезы генерировать специалисты будут, видимо, из головы, и никаких знаний о том, какие TTP, кто и против кого применяет, нам не нужно. Как и IOC. Не считая того, что, вообще-то, это один из самых сложных процессов, и главная его проблема даже не в технических решениях, а в рабочей силе — людей, умеющих делать TH, на рынке не много.
Откуда такая интересная и странная метрика? И такая однозначная? А если у заказчика инфраструктура на 8 часовых поясов и на 20к+ источников данных, не считая сетевого оборудования?
Глобально, тема поднята интересная, но:
Смешанные чувства оставила статья. Тема интересная, но раскрыта однобоко и странно.
Первым этапом может быть Log Management (LM) в виде специализированного решения или унифицированного варианта, типа Elastic Stack
ELK для LM — такое себе решение. Да, многое умеет «из коробки», но отсутствие агрегации и крайне тяжкий кросс-индексный поиск — это проблема. Со вторым еще можно жить, а вот требования к хранилищу будут очень жесткие.
Организовать Threat Hunting и расследование инцидентов. LM для данной задачи – единственная необходимая платформа
Точно знаете, что такое threat hunting? А гипотезы генерировать специалисты будут, видимо, из головы, и никаких знаний о том, какие TTP, кто и против кого применяет, нам не нужно. Как и IOC. Не считая того, что, вообще-то, это один из самых сложных процессов, и главная его проблема даже не в технических решениях, а в рабочей силе — людей, умеющих делать TH, на рынке не много.
Обе задачи решаем итерационно. Хороший показатель – 15 инцидентов на смену аналитика. Достигли его – закручиваем гайки дальше.
Откуда такая интересная и странная метрика? И такая однозначная? А если у заказчика инфраструктура на 8 часовых поясов и на 20к+ источников данных, не считая сетевого оборудования?
Глобально, тема поднята интересная, но:
- Куда-то пропала организационная часть. Мы просто ставим новые коробочки, и у нас начинают выявляться инциденты. К сожалению, так не бывает. Внедрение таких вещей всегда должен сопровождать консалтинг по построению процессов.
- Странная нумерация. IPDS — в самом конце? Серьезно? Да, автор пишет, что оно «скорее всего уже есть», только вот если заказчик еще не дорос до IPDS — до построения SOC ему еще очень долго расти.
- Вопрос масштабирования — только упоминание о том, что надо бы делать проекты маленькими кусочками, с чем я полностью согласен.
- И самое главное, о чем не любят говорить — обоснование таких масштабных задач и, собственно, та ценность, которую SOC создает своему заказчику, не важно, внутреннему или внешнему. Про это вообще ни слова.
Смешанные чувства оставила статья. Тема интересная, но раскрыта однобоко и странно.
Статья обзорная, она не ставит перед собой цель уйти глубоко в детали. Её задача — выработать общий понятийный аппарат с теми, для кого направление мониторинга не основное, а одно из многих. Для непрофильных компаний это частая история. Всё, что выглядит как технические детали призвано иллюстрировать необходимость, а не создать законченное видение автора, и уж тем более не заменить необходимость разработки проектной документации. Любое из направлений, обозначенных в статье, можно расписать на книгу или несколько и это будет не истина в последний инстанции, так как здесь пересекается множество плоскостей — техническая, организационная, экономическая и пр.
Далее кратко по пунктам:
Может быть, но это не останавливает производителей от его использования. Я знаю минимум 4 отечественных SIEM на нём. Зарубежные появились раньше ELK, поэтому у них почти всегда самописные базы, они не показатель. Это не мешает производителю самого ELK строить SIEM на нём, исходя из запросов заказчиков. Попутно дорабатывая кросс-кластерный поиск и агрегацию, что прослеживается по последним релизам. А дальше сравнение, плюсы и минусы можно на отдельную статью или цикл расписать. Я бы такую с удовольствием прочитал.
Использование LM как основного и почти единственного инструмента для TH это не моя оригинальная мысль, достаточно посмотреть эфиры некоторых русскоязычных ресурсов на эту тему за последний месяц. И основные источники гипотез для начинающих в этом направлений свой путь тоже очень простые и не требуют технических средств — модели ИБ (тот же ATT&CK), бюллетени уязвимостей, да даже новостные рассылки, тот же Exchange несколько недель назад упомянули все, даже не отраслевые СМИ и новостные каналы.
Дальше можно бесконечно погружаться в TI тактический и стратегический, проверку статистики от специализированных (UEBA, NBA) и систем общего профиля, систему обратной связи от сотрудников и прочего. Но это не база, а потому не предмет данной статьи.
Метрика из практики MSSP, подтвержденная и теорией из книг типа «Ten Strategies of a World-Class Cybersecurity Operations Center». Это метрика на аналитика, сколько кейсов он сможет реально расследовать, а не засунуть за 2 минуты в категорию ЛПС\ЛОС. Сколько нужно таких аналитиков параллельно — это другой вопрос и может решаться очень по разному.
Отсечена заголовком статьи. При этом безусловно, тема важная, даже более, чем техническая.
После пункта 2 система нумерация чисто условная, о чем в статье написано. По сути пункт про IPS открывает тему трафика в мониторинге в рамках данной статьи и тут рассматривается не как самостоятельное решение, как и когда внедрять которое — отдельный вопрос.
Статья не погружается в технические детали. Их десятки по каждому классу систем и каждому производителю.
Однобоко — так и планировалось, иначе можно писать минимум книгу. Странно — на усмотрение читателя. Учту как заявку на расширение тематики в будущих публикациях, если кто то не успеет осветить смежные вопросы раньше и лучше меня. Я за то, чтобы появилась статья «Все вопросы мониторинга ИБ на 10 страницах» или хотя бы «Мониторинг ИБ от А до Я». Но пока десятки книг от разных авторов никто не смог скомпоновать.
Далее кратко по пунктам:
ELK для LM — такое себе решение.
Может быть, но это не останавливает производителей от его использования. Я знаю минимум 4 отечественных SIEM на нём. Зарубежные появились раньше ELK, поэтому у них почти всегда самописные базы, они не показатель. Это не мешает производителю самого ELK строить SIEM на нём, исходя из запросов заказчиков. Попутно дорабатывая кросс-кластерный поиск и агрегацию, что прослеживается по последним релизам. А дальше сравнение, плюсы и минусы можно на отдельную статью или цикл расписать. Я бы такую с удовольствием прочитал.
А гипотезы генерировать специалисты будут, видимо, из головы, и никаких знаний о том, какие TTP, кто и против кого применяет, нам не нужно.
Использование LM как основного и почти единственного инструмента для TH это не моя оригинальная мысль, достаточно посмотреть эфиры некоторых русскоязычных ресурсов на эту тему за последний месяц. И основные источники гипотез для начинающих в этом направлений свой путь тоже очень простые и не требуют технических средств — модели ИБ (тот же ATT&CK), бюллетени уязвимостей, да даже новостные рассылки, тот же Exchange несколько недель назад упомянули все, даже не отраслевые СМИ и новостные каналы.
Дальше можно бесконечно погружаться в TI тактический и стратегический, проверку статистики от специализированных (UEBA, NBA) и систем общего профиля, систему обратной связи от сотрудников и прочего. Но это не база, а потому не предмет данной статьи.
Откуда такая интересная и странная метрика? И такая однозначная? А если у заказчика инфраструктура на 8 часовых поясов и на 20к+ источников данных, не считая сетевого оборудования?
Метрика из практики MSSP, подтвержденная и теорией из книг типа «Ten Strategies of a World-Class Cybersecurity Operations Center». Это метрика на аналитика, сколько кейсов он сможет реально расследовать, а не засунуть за 2 минуты в категорию ЛПС\ЛОС. Сколько нужно таких аналитиков параллельно — это другой вопрос и может решаться очень по разному.
Куда-то пропала организационная часть
Отсечена заголовком статьи. При этом безусловно, тема важная, даже более, чем техническая.
Странная нумерация. IPDS — в самом конце? Серьезно?
После пункта 2 система нумерация чисто условная, о чем в статье написано. По сути пункт про IPS открывает тему трафика в мониторинге в рамках данной статьи и тут рассматривается не как самостоятельное решение, как и когда внедрять которое — отдельный вопрос.
Вопрос масштабирования
Статья не погружается в технические детали. Их десятки по каждому классу систем и каждому производителю.
И самое главное, о чем не любят говорить — обоснование таких масштабных задач и, собственно, та ценность, которую SOC создает своему заказчику, не важно, внутреннему или внешнему. Про это вообще ни слова.Оценка рисков, часть из которых риски ИБ, часть из которых решаются методом минимизации, часть из которых за счёт мониторинга — отдельная область знаний. В статью не вместилась.
Смешанные чувства оставила статья. Тема интересная, но раскрыта однобоко и странно.
Однобоко — так и планировалось, иначе можно писать минимум книгу. Странно — на усмотрение читателя. Учту как заявку на расширение тематики в будущих публикациях, если кто то не успеет осветить смежные вопросы раньше и лучше меня. Я за то, чтобы появилась статья «Все вопросы мониторинга ИБ на 10 страницах» или хотя бы «Мониторинг ИБ от А до Я». Но пока десятки книг от разных авторов никто не смог скомпоновать.
Статья обзорная, она не ставит перед собой цель уйти глубоко в детали. Её задача — выработать общий понятийный аппарат с теми, для кого направление мониторинга не основное, а одно из многих.
Хм. В моей голове понятийный аппарат для мониторинга ИБ уже достаточно неплохо разобран в 27k и NIST SP 800-53. Он там не до конца однороден, т.к. разны организации это делают, но тем не менее, вполне хорош. Основные термины там разобраны неплохо. Хотя место для срача а-ля «что есть событие ИБ, а что есть инцидент ИБ» остается, да. И еще есть термин, который не ясно, как вводить в русскоязычную документацию — security breach.
Может быть, но это не останавливает производителей от его использования. Я знаю минимум 4 отечественных SIEM на нём.
И все они добавляют свои костыли для агрегации и корреляции.
Это не мешает производителю самого ELK строить SIEM на нём, исходя из запросов заказчиков. Попутно дорабатывая кросс-кластерный поиск и агрегацию, что прослеживается по последним релизам.
Всё так, но у них эти фичи появляются уже в платной версии, которая стоит, как настоящий SIEM.
Так-то, у них и EDR есть свой.
Использование LM как основного и почти единственного инструмента для TH это не моя оригинальная мысль, достаточно посмотреть эфиры некоторых русскоязычных ресурсов на эту тему за последний месяц. И основные источники гипотез для начинающих в этом направлений свой путь тоже очень простые и не требуют технических средств — модели ИБ (тот же ATT&CK), бюллетени уязвимостей, да даже новостные рассылки, тот же Exchange несколько недель назад упомянули все, даже не отраслевые СМИ и новостные каналы.
У меня есть серьезное подозрение, что русскоязычные авторы это пишут потому, что у них (а у нас большая часть авторов — это сотрудники вендоров) просто нет ничего другого. И, в любом случае, хантинг — это сложный и тяжелый процесс, думать о котором имеет смысл только тогда, когда уже есть baseline-ы по мониторингу, процессы управления инцидентами работают, и мы уже перешли к весьма зрелому SOC-у.
Метрика из практики MSSP, подтвержденная и теорией из книг типа «Ten Strategies of a World-Class Cybersecurity Operations Center». Это метрика на аналитика, сколько кейсов он сможет реально расследовать, а не засунуть за 2 минуты в категорию ЛПС\ЛОС. Сколько нужно таких аналитиков параллельно — это другой вопрос и может решаться очень по разному.
Как мне кажется, это можно рассматривать только как пристрелочное значение для определение количества аналитиков. Как метрика эффективности внедрения она все-таки не подойдет, по моему мнению.
Я за то, чтобы появилась статья «Все вопросы мониторинга ИБ на 10 страницах» или хотя бы «Мониторинг ИБ от А до Я». Но пока десятки книг от разных авторов никто не смог скомпоновать.
Боюсь, что это будет не статья, а цикл уровня четверокнижия Таненбаума :)
Всё в целом так, как вы говорите. Но как минимум в русскоязычном сегменте не многие так глубоко погружаются. Тот же NIST — очень хороший стандарт, на хабре даже есть на него обзоры. Только лучше всё же читать весь цикл:
А это уже несколько тысяч страниц хотя бы по диагонали.
Эта статья прежде всего ликбез для тех, для кого тема не является основной. Краткая шпаргалка, которой можно поделиться или использовать самому, если нужно быстрое и общее понимание. Та же тема КИИ сейчас активно развивается. Хочется, чтобы организации не только получали подтверждение соответствия «на бумаге», но и за почти те же деньги имели реальные результаты уже сейчас. Тут все в плюсе будут.
А это уже несколько тысяч страниц хотя бы по диагонали.
Эта статья прежде всего ликбез для тех, для кого тема не является основной. Краткая шпаргалка, которой можно поделиться или использовать самому, если нужно быстрое и общее понимание. Та же тема КИИ сейчас активно развивается. Хочется, чтобы организации не только получали подтверждение соответствия «на бумаге», но и за почти те же деньги имели реальные результаты уже сейчас. Тут все в плюсе будут.
Sign up to leave a comment.
Технические средства мониторинга ИБ