Еще раз здравствуйте.
1. Проблема с парсингом может быть решена несколькими способами, в том числе и Вашим. В некоторых случаях мы используем вариант, описанный Вами, в других — который описан в статье. Сказать что проще, что сложнее однозначно нельзя.
2. Действительно в статье упущен момент, что на скриншоте приведен готовый fieldset, универсальный для большинства сетевых событий. Но задача была показать в первую очередь факт срабатывания, основную смысловую нагрузку в этом случае несет следующих скриншот.
Полного перечня показателей SOMM и методологии/формул оценки я в открытом доступе не видел. Готов поделиться личными знаниями и подходами, но лучше за рамками общих комментариев.
1. По поводу событий с Cisco ASA, Вы действительно правы и событие 713228 несет в себе достаточную информацию. Проблема, в свое время, была на стороне HP ArcSight — с парсингом событий коннектором, он брал только локальный ip-адрес из этого события. В последних версиях коннектора это было исправлено, поэтому сейчас использовать данное базовое правило не обязательно.
2. По поводу выбора переменных — скриншот не совсем удачный, переменных намного больше, но все решил не помещать. Используются в сетевых событий следующие: attacker adress, att. port, att. geo, att. host name, destination adress, dest. port, dest. geo, dest. host name, mrt, priority, event name, device vendor, device product, bytes in, bytes out и другие
Наша практика показывает, что зрелость клиента является крайне важным требованием, но не блокирующим для запуска сервиса. Базовый уровень мониторинга — контроль безопасности сети и инфраструктуры — не требует ничего экстраординарного и реализуем практически на любой инструментальной и процессной базе, при этом давая вполне понятный результат. Но, безусловно, чем более строгие и зрелые процессы в клиенте, тем полнее мы вместе с ним сможем видеть общую картину безопасности и тем более глубокий и эффективный анализ сможем давать по инцидентам.
В рамках описанных Вами требований:
-инвентаризацию ресурсов клиента мы проводим в рамках подключения. Часть информации: адресация, имена, используемые сервисы и процессы — заполняются в полуавтоматическом режиме на этапе профилирования системы. Остальное — владельцы, критичность, классификация информации на системах — это совместный процесс изысканий, но по ключевым системам, требующим защиты, он, как правило, трудностей не вызывает.
-обнаружение новых ассетов и сервисов также проходит практически автоматически. Нет более верного способа (по крайней мере, мне неизвестно) обнаружить сервер или сетевой сервис, чем увидеть к нему сетевое соединение :) Если мы видим принципиально новую, ранее неизвестную сессию в сети/периметре/подключенной системе — это повод завести инцидент и совместно с клиентом понять, насколько это нормальное изменение. Например, зачастую случается, что одна ошибка сетевого администратора может открыть для интернета больший список незащищенных и незапланированных для Интернет-сегмента систем. Это сценарий всегда бывает одним из первых, который просят настроить нас наши клиенты
-с учетными записями ситуация аналогичная. Мы можем получить очень большой объем информации на основании профилирования и сбора информации с ключевых систем. Дальше необходимо совместно разбирать и причесывать данную информацию (заводить список учетных записей общего доступа, добавлять списки исключений, сопоставлять учетные записи в разных системах). Без IDM и процессов — катастрофически сложная задача для всех систем компании. Но для ключевых систем и сервисов — значительно менее трудоемкая
-а вот с требованиями к защите серверов и рабочих станций ситуация значительно сложнее. Здесь мы можем лишь выдавать рекомендации клиенту, но не можем повлиять на ситуацию так или иначе. И отсутствие «упорядоченности» в этой части сказывается на эффективности жизни SOC, сокращая объем полезного эффекта.
Хочется резюмировать, что полностью заменить собственные процессы мы клиенту не можем и не стремимся. Но дать инструмент для того, чтобы повысить безопасность и выстроить процессы вокруг ключевых систем и сервисов — в состоянии, если Заказчик заинтересован в этом.
1. Я бы сказал, что оба ответа верны. Естественно, опыт западных SOC мы учитывали, но в итоге постарались построить нечто свое, адаптированное под российскую специфику. И «шлифовка» текущего сервиса не прекращается ни на секунду.
2. Как ни банально, но очень разный. Одни клиенты готовы сотрудничать с нами в рамках кейсов инфраструктурной безопасности или задач compliance, с другими мы выстраиваем модель по контролю инцидентов в бизнес-системах и выявлении нарушений в бизнес-процессах и поиску внутреннего мошенничества. К тому же своим клиентам мы с радостью устраиваем экскурсии: как в ЦОД, так и в сам центр мониторинга и реагирования. Возможность лично увидеть команду, которая тебя обслуживает, снимает большой слой недоверия.
3. Безусловно подписываются. Способы контроля можно применять разные, и я, к сожалению, не готов освещать эту тему в деталях. Вопрос подбора, обучения и контроля персонала очень тонкий и объемный, по объему тянет на отдельную статью. Возможно, через какое-то время буду готов об этом написать.
4. Одного специального клиента не было. Было общее ощущение, что рынок к этому готов. Если еще два-три года назад при упоминании терминов «аутсорсинг ИБ» клиенты демонстрировали явное неприятие этой идеи, то сейчас как минимум обсуждать тематику готовы многие. И спрос рынка и наших клиентов в том числе и породил необходимость запуска услуги.
Можно отметить, что западные MSS получили свой бурный рост примерно 4-5 лет назад. Теперь востребованность тематики дошла и до России.
5. В этом и смысл нашего сервиса. Если у клиентов есть свой 24*7, его потребность в наших услугах существенно ниже.
Для этого с клиентов на старте согласовывается профиль оповещения: какие инциденты готовы ждать до утра и по ним можно отправить почтовое уведомление, а по каким необходимо будить специалистов ASAP в не зависимости от дня недели и времени суток.
Возможен и второй вариант — когда клиент доверяет нам управление своими активными средствами защиты и тогда предотвращение/блокирование инцидента мы можем провести в режиме единого окна — команда разбора инцидентов передает информацию команде администрирования.
Внутренняя приоретизация инцидентов у нас ведется от 0 до 10, для каждого свои параметры SLM. Внешняя ведется по трем уровням: высокий, средний и низкий. По нашему опыту, это наиболее комфортная схема для клиентов.
Следующий выпуск планируем в течении двух недель, следите за нашим блогом :)
1. Проблема с парсингом может быть решена несколькими способами, в том числе и Вашим. В некоторых случаях мы используем вариант, описанный Вами, в других — который описан в статье. Сказать что проще, что сложнее однозначно нельзя.
2. Действительно в статье упущен момент, что на скриншоте приведен готовый fieldset, универсальный для большинства сетевых событий. Но задача была показать в первую очередь факт срабатывания, основную смысловую нагрузку в этом случае несет следующих скриншот.
Задержался с ответом, извиняюсь. У HP есть сервис по оценке зрелости существующего SOC, в рамках него они проводят очень детальный аудит — www8.hp.com/h20195/v2/GetPDF.aspx%2F4AA4-4144ENN.pdf
Полного перечня показателей SOMM и методологии/формул оценки я в открытом доступе не видел. Готов поделиться личными знаниями и подходами, но лучше за рамками общих комментариев.
1. По поводу событий с Cisco ASA, Вы действительно правы и событие 713228 несет в себе достаточную информацию. Проблема, в свое время, была на стороне HP ArcSight — с парсингом событий коннектором, он брал только локальный ip-адрес из этого события. В последних версиях коннектора это было исправлено, поэтому сейчас использовать данное базовое правило не обязательно.
2. По поводу выбора переменных — скриншот не совсем удачный, переменных намного больше, но все решил не помещать. Используются в сетевых событий следующие: attacker adress, att. port, att. geo, att. host name, destination adress, dest. port, dest. geo, dest. host name, mrt, priority, event name, device vendor, device product, bytes in, bytes out и другие
В рамках описанных Вами требований:
-инвентаризацию ресурсов клиента мы проводим в рамках подключения. Часть информации: адресация, имена, используемые сервисы и процессы — заполняются в полуавтоматическом режиме на этапе профилирования системы. Остальное — владельцы, критичность, классификация информации на системах — это совместный процесс изысканий, но по ключевым системам, требующим защиты, он, как правило, трудностей не вызывает.
-обнаружение новых ассетов и сервисов также проходит практически автоматически. Нет более верного способа (по крайней мере, мне неизвестно) обнаружить сервер или сетевой сервис, чем увидеть к нему сетевое соединение :) Если мы видим принципиально новую, ранее неизвестную сессию в сети/периметре/подключенной системе — это повод завести инцидент и совместно с клиентом понять, насколько это нормальное изменение. Например, зачастую случается, что одна ошибка сетевого администратора может открыть для интернета больший список незащищенных и незапланированных для Интернет-сегмента систем. Это сценарий всегда бывает одним из первых, который просят настроить нас наши клиенты
-с учетными записями ситуация аналогичная. Мы можем получить очень большой объем информации на основании профилирования и сбора информации с ключевых систем. Дальше необходимо совместно разбирать и причесывать данную информацию (заводить список учетных записей общего доступа, добавлять списки исключений, сопоставлять учетные записи в разных системах). Без IDM и процессов — катастрофически сложная задача для всех систем компании. Но для ключевых систем и сервисов — значительно менее трудоемкая
-а вот с требованиями к защите серверов и рабочих станций ситуация значительно сложнее. Здесь мы можем лишь выдавать рекомендации клиенту, но не можем повлиять на ситуацию так или иначе. И отсутствие «упорядоченности» в этой части сказывается на эффективности жизни SOC, сокращая объем полезного эффекта.
Хочется резюмировать, что полностью заменить собственные процессы мы клиенту не можем и не стремимся. Но дать инструмент для того, чтобы повысить безопасность и выстроить процессы вокруг ключевых систем и сервисов — в состоянии, если Заказчик заинтересован в этом.
1. Я бы сказал, что оба ответа верны. Естественно, опыт западных SOC мы учитывали, но в итоге постарались построить нечто свое, адаптированное под российскую специфику. И «шлифовка» текущего сервиса не прекращается ни на секунду.
2. Как ни банально, но очень разный. Одни клиенты готовы сотрудничать с нами в рамках кейсов инфраструктурной безопасности или задач compliance, с другими мы выстраиваем модель по контролю инцидентов в бизнес-системах и выявлении нарушений в бизнес-процессах и поиску внутреннего мошенничества. К тому же своим клиентам мы с радостью устраиваем экскурсии: как в ЦОД, так и в сам центр мониторинга и реагирования. Возможность лично увидеть команду, которая тебя обслуживает, снимает большой слой недоверия.
3. Безусловно подписываются. Способы контроля можно применять разные, и я, к сожалению, не готов освещать эту тему в деталях. Вопрос подбора, обучения и контроля персонала очень тонкий и объемный, по объему тянет на отдельную статью. Возможно, через какое-то время буду готов об этом написать.
4. Одного специального клиента не было. Было общее ощущение, что рынок к этому готов. Если еще два-три года назад при упоминании терминов «аутсорсинг ИБ» клиенты демонстрировали явное неприятие этой идеи, то сейчас как минимум обсуждать тематику готовы многие. И спрос рынка и наших клиентов в том числе и породил необходимость запуска услуги.
Можно отметить, что западные MSS получили свой бурный рост примерно 4-5 лет назад. Теперь востребованность тематики дошла и до России.
5. В этом и смысл нашего сервиса. Если у клиентов есть свой 24*7, его потребность в наших услугах существенно ниже.
Для этого с клиентов на старте согласовывается профиль оповещения: какие инциденты готовы ждать до утра и по ним можно отправить почтовое уведомление, а по каким необходимо будить специалистов ASAP в не зависимости от дня недели и времени суток.
Возможен и второй вариант — когда клиент доверяет нам управление своими активными средствами защиты и тогда предотвращение/блокирование инцидента мы можем провести в режиме единого окна — команда разбора инцидентов передает информацию команде администрирования.
Интерес к теме и глубина погружения специалистов, по нашей оценке, качественно растет последние пару лет. Что не может не радовать :)
Внутренняя приоретизация инцидентов у нас ведется от 0 до 10, для каждого свои параметры SLM. Внешняя ведется по трем уровням: высокий, средний и низкий. По нашему опыту, это наиболее комфортная схема для клиентов.
Следующий выпуск планируем в течении двух недель, следите за нашим блогом :)