Комментарии 6
А что для внедрения SOC требуете от заказчика? С какого уровня зрелости организации есть смысл внедрять SOC? Ведь как минимум у заказчика должны быть:
— система инвентаризации ресурсов (серверов, информсистем, сетевого оборудования, сервисов) с актуальной информацией;
— должны регулярно обнаруживаться новые ассеты, сервисы;
— все ассеты должны быть строго категоризированы с точки зрения критичности, типа (веб-сервис) и т.п.;
— для максимального эффекта от акторов (actors, если правильно помню из документации арксайта), должен быть строгий учет людей и их учеток, а соответственно внедрены IdM-подобные решения;
— строгие требования к защите серверов и рабочих мест (банальных админских прав быть не должно, запуск сетевых служб на внешних IP должен регламентироваться).
— система инвентаризации ресурсов (серверов, информсистем, сетевого оборудования, сервисов) с актуальной информацией;
— должны регулярно обнаруживаться новые ассеты, сервисы;
— все ассеты должны быть строго категоризированы с точки зрения критичности, типа (веб-сервис) и т.п.;
— для максимального эффекта от акторов (actors, если правильно помню из документации арксайта), должен быть строгий учет людей и их учеток, а соответственно внедрены IdM-подобные решения;
— строгие требования к защите серверов и рабочих мест (банальных админских прав быть не должно, запуск сетевых служб на внешних IP должен регламентироваться).
Наша практика показывает, что зрелость клиента является крайне важным требованием, но не блокирующим для запуска сервиса. Базовый уровень мониторинга — контроль безопасности сети и инфраструктуры — не требует ничего экстраординарного и реализуем практически на любой инструментальной и процессной базе, при этом давая вполне понятный результат. Но, безусловно, чем более строгие и зрелые процессы в клиенте, тем полнее мы вместе с ним сможем видеть общую картину безопасности и тем более глубокий и эффективный анализ сможем давать по инцидентам.
В рамках описанных Вами требований:
-инвентаризацию ресурсов клиента мы проводим в рамках подключения. Часть информации: адресация, имена, используемые сервисы и процессы — заполняются в полуавтоматическом режиме на этапе профилирования системы. Остальное — владельцы, критичность, классификация информации на системах — это совместный процесс изысканий, но по ключевым системам, требующим защиты, он, как правило, трудностей не вызывает.
-обнаружение новых ассетов и сервисов также проходит практически автоматически. Нет более верного способа (по крайней мере, мне неизвестно) обнаружить сервер или сетевой сервис, чем увидеть к нему сетевое соединение :) Если мы видим принципиально новую, ранее неизвестную сессию в сети/периметре/подключенной системе — это повод завести инцидент и совместно с клиентом понять, насколько это нормальное изменение. Например, зачастую случается, что одна ошибка сетевого администратора может открыть для интернета больший список незащищенных и незапланированных для Интернет-сегмента систем. Это сценарий всегда бывает одним из первых, который просят настроить нас наши клиенты
-с учетными записями ситуация аналогичная. Мы можем получить очень большой объем информации на основании профилирования и сбора информации с ключевых систем. Дальше необходимо совместно разбирать и причесывать данную информацию (заводить список учетных записей общего доступа, добавлять списки исключений, сопоставлять учетные записи в разных системах). Без IDM и процессов — катастрофически сложная задача для всех систем компании. Но для ключевых систем и сервисов — значительно менее трудоемкая
-а вот с требованиями к защите серверов и рабочих станций ситуация значительно сложнее. Здесь мы можем лишь выдавать рекомендации клиенту, но не можем повлиять на ситуацию так или иначе. И отсутствие «упорядоченности» в этой части сказывается на эффективности жизни SOC, сокращая объем полезного эффекта.
Хочется резюмировать, что полностью заменить собственные процессы мы клиенту не можем и не стремимся. Но дать инструмент для того, чтобы повысить безопасность и выстроить процессы вокруг ключевых систем и сервисов — в состоянии, если Заказчик заинтересован в этом.
В рамках описанных Вами требований:
-инвентаризацию ресурсов клиента мы проводим в рамках подключения. Часть информации: адресация, имена, используемые сервисы и процессы — заполняются в полуавтоматическом режиме на этапе профилирования системы. Остальное — владельцы, критичность, классификация информации на системах — это совместный процесс изысканий, но по ключевым системам, требующим защиты, он, как правило, трудностей не вызывает.
-обнаружение новых ассетов и сервисов также проходит практически автоматически. Нет более верного способа (по крайней мере, мне неизвестно) обнаружить сервер или сетевой сервис, чем увидеть к нему сетевое соединение :) Если мы видим принципиально новую, ранее неизвестную сессию в сети/периметре/подключенной системе — это повод завести инцидент и совместно с клиентом понять, насколько это нормальное изменение. Например, зачастую случается, что одна ошибка сетевого администратора может открыть для интернета больший список незащищенных и незапланированных для Интернет-сегмента систем. Это сценарий всегда бывает одним из первых, который просят настроить нас наши клиенты
-с учетными записями ситуация аналогичная. Мы можем получить очень большой объем информации на основании профилирования и сбора информации с ключевых систем. Дальше необходимо совместно разбирать и причесывать данную информацию (заводить список учетных записей общего доступа, добавлять списки исключений, сопоставлять учетные записи в разных системах). Без IDM и процессов — катастрофически сложная задача для всех систем компании. Но для ключевых систем и сервисов — значительно менее трудоемкая
-а вот с требованиями к защите серверов и рабочих станций ситуация значительно сложнее. Здесь мы можем лишь выдавать рекомендации клиенту, но не можем повлиять на ситуацию так или иначе. И отсутствие «упорядоченности» в этой части сказывается на эффективности жизни SOC, сокращая объем полезного эффекта.
Хочется резюмировать, что полностью заменить собственные процессы мы клиенту не можем и не стремимся. Но дать инструмент для того, чтобы повысить безопасность и выстроить процессы вокруг ключевых систем и сервисов — в состоянии, если Заказчик заинтересован в этом.
По ASA пример чертовски некорректен. Событие 713228 и 602303 содержат имя пользователя:
www.cisco.com/c/en/us/td/docs/security/asa/syslog-guide/syslogs/logmsgs.html
Причем события 713228 достаточно, чтобы считать, что установлено успешное IPSEC соединение, понять откуда оно установлено и какой адрес назначен клиенту.
Так же странным выглядит брать в качестве переменных сорс адрес, имя пользователя и локационную инфу.
www.cisco.com/c/en/us/td/docs/security/asa/syslog-guide/syslogs/logmsgs.html
Причем события 713228 достаточно, чтобы считать, что установлено успешное IPSEC соединение, понять откуда оно установлено и какой адрес назначен клиенту.
Так же странным выглядит брать в качестве переменных сорс адрес, имя пользователя и локационную инфу.
Добрый день. По Вашим комментариям:
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 и другие
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 и другие
Проблема с парсингом решается с помощью сабагента. Узнать номер submessage используется для события 713228 можно в саппорте.
Вопрос по переменным в том, что непонятно зачем они там. Если бы было понятно, что это глобальные переменные, то можно было бы это понять, но без этого уточнения выглядит скриншот очень странным с точки зрения реализации.
Вопрос по переменным в том, что непонятно зачем они там. Если бы было понятно, что это глобальные переменные, то можно было бы это понять, но без этого уточнения выглядит скриншот очень странным с точки зрения реализации.
Еще раз здравствуйте.
1. Проблема с парсингом может быть решена несколькими способами, в том числе и Вашим. В некоторых случаях мы используем вариант, описанный Вами, в других — который описан в статье. Сказать что проще, что сложнее однозначно нельзя.
2. Действительно в статье упущен момент, что на скриншоте приведен готовый fieldset, универсальный для большинства сетевых событий. Но задача была показать в первую очередь факт срабатывания, основную смысловую нагрузку в этом случае несет следующих скриншот.
1. Проблема с парсингом может быть решена несколькими способами, в том числе и Вашим. В некоторых случаях мы используем вариант, описанный Вами, в других — который описан в статье. Сказать что проще, что сложнее однозначно нельзя.
2. Действительно в статье упущен момент, что на скриншоте приведен готовый fieldset, универсальный для большинства сетевых событий. Но задача была показать в первую очередь факт срабатывания, основную смысловую нагрузку в этом случае несет следующих скриншот.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
JSOC: как готовить инциденты