Comments 6
А что для внедрения SOC требуете от заказчика? С какого уровня зрелости организации есть смысл внедрять SOC? Ведь как минимум у заказчика должны быть:
— система инвентаризации ресурсов (серверов, информсистем, сетевого оборудования, сервисов) с актуальной информацией;
— должны регулярно обнаруживаться новые ассеты, сервисы;
— все ассеты должны быть строго категоризированы с точки зрения критичности, типа (веб-сервис) и т.п.;
— для максимального эффекта от акторов (actors, если правильно помню из документации арксайта), должен быть строгий учет людей и их учеток, а соответственно внедрены IdM-подобные решения;
— строгие требования к защите серверов и рабочих мест (банальных админских прав быть не должно, запуск сетевых служб на внешних IP должен регламентироваться).
— система инвентаризации ресурсов (серверов, информсистем, сетевого оборудования, сервисов) с актуальной информацией;
— должны регулярно обнаруживаться новые ассеты, сервисы;
— все ассеты должны быть строго категоризированы с точки зрения критичности, типа (веб-сервис) и т.п.;
— для максимального эффекта от акторов (actors, если правильно помню из документации арксайта), должен быть строгий учет людей и их учеток, а соответственно внедрены IdM-подобные решения;
— строгие требования к защите серверов и рабочих мест (банальных админских прав быть не должно, запуск сетевых служб на внешних IP должен регламентироваться).
0
Наша практика показывает, что зрелость клиента является крайне важным требованием, но не блокирующим для запуска сервиса. Базовый уровень мониторинга — контроль безопасности сети и инфраструктуры — не требует ничего экстраординарного и реализуем практически на любой инструментальной и процессной базе, при этом давая вполне понятный результат. Но, безусловно, чем более строгие и зрелые процессы в клиенте, тем полнее мы вместе с ним сможем видеть общую картину безопасности и тем более глубокий и эффективный анализ сможем давать по инцидентам.
В рамках описанных Вами требований:
-инвентаризацию ресурсов клиента мы проводим в рамках подключения. Часть информации: адресация, имена, используемые сервисы и процессы — заполняются в полуавтоматическом режиме на этапе профилирования системы. Остальное — владельцы, критичность, классификация информации на системах — это совместный процесс изысканий, но по ключевым системам, требующим защиты, он, как правило, трудностей не вызывает.
-обнаружение новых ассетов и сервисов также проходит практически автоматически. Нет более верного способа (по крайней мере, мне неизвестно) обнаружить сервер или сетевой сервис, чем увидеть к нему сетевое соединение :) Если мы видим принципиально новую, ранее неизвестную сессию в сети/периметре/подключенной системе — это повод завести инцидент и совместно с клиентом понять, насколько это нормальное изменение. Например, зачастую случается, что одна ошибка сетевого администратора может открыть для интернета больший список незащищенных и незапланированных для Интернет-сегмента систем. Это сценарий всегда бывает одним из первых, который просят настроить нас наши клиенты
-с учетными записями ситуация аналогичная. Мы можем получить очень большой объем информации на основании профилирования и сбора информации с ключевых систем. Дальше необходимо совместно разбирать и причесывать данную информацию (заводить список учетных записей общего доступа, добавлять списки исключений, сопоставлять учетные записи в разных системах). Без IDM и процессов — катастрофически сложная задача для всех систем компании. Но для ключевых систем и сервисов — значительно менее трудоемкая
-а вот с требованиями к защите серверов и рабочих станций ситуация значительно сложнее. Здесь мы можем лишь выдавать рекомендации клиенту, но не можем повлиять на ситуацию так или иначе. И отсутствие «упорядоченности» в этой части сказывается на эффективности жизни SOC, сокращая объем полезного эффекта.
Хочется резюмировать, что полностью заменить собственные процессы мы клиенту не можем и не стремимся. Но дать инструмент для того, чтобы повысить безопасность и выстроить процессы вокруг ключевых систем и сервисов — в состоянии, если Заказчик заинтересован в этом.
В рамках описанных Вами требований:
-инвентаризацию ресурсов клиента мы проводим в рамках подключения. Часть информации: адресация, имена, используемые сервисы и процессы — заполняются в полуавтоматическом режиме на этапе профилирования системы. Остальное — владельцы, критичность, классификация информации на системах — это совместный процесс изысканий, но по ключевым системам, требующим защиты, он, как правило, трудностей не вызывает.
-обнаружение новых ассетов и сервисов также проходит практически автоматически. Нет более верного способа (по крайней мере, мне неизвестно) обнаружить сервер или сетевой сервис, чем увидеть к нему сетевое соединение :) Если мы видим принципиально новую, ранее неизвестную сессию в сети/периметре/подключенной системе — это повод завести инцидент и совместно с клиентом понять, насколько это нормальное изменение. Например, зачастую случается, что одна ошибка сетевого администратора может открыть для интернета больший список незащищенных и незапланированных для Интернет-сегмента систем. Это сценарий всегда бывает одним из первых, который просят настроить нас наши клиенты
-с учетными записями ситуация аналогичная. Мы можем получить очень большой объем информации на основании профилирования и сбора информации с ключевых систем. Дальше необходимо совместно разбирать и причесывать данную информацию (заводить список учетных записей общего доступа, добавлять списки исключений, сопоставлять учетные записи в разных системах). Без IDM и процессов — катастрофически сложная задача для всех систем компании. Но для ключевых систем и сервисов — значительно менее трудоемкая
-а вот с требованиями к защите серверов и рабочих станций ситуация значительно сложнее. Здесь мы можем лишь выдавать рекомендации клиенту, но не можем повлиять на ситуацию так или иначе. И отсутствие «упорядоченности» в этой части сказывается на эффективности жизни SOC, сокращая объем полезного эффекта.
Хочется резюмировать, что полностью заменить собственные процессы мы клиенту не можем и не стремимся. Но дать инструмент для того, чтобы повысить безопасность и выстроить процессы вокруг ключевых систем и сервисов — в состоянии, если Заказчик заинтересован в этом.
0
По 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 соединение, понять откуда оно установлено и какой адрес назначен клиенту.
Так же странным выглядит брать в качестве переменных сорс адрес, имя пользователя и локационную инфу.
0
Добрый день. По Вашим комментариям:
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 и другие
0
Проблема с парсингом решается с помощью сабагента. Узнать номер submessage используется для события 713228 можно в саппорте.
Вопрос по переменным в том, что непонятно зачем они там. Если бы было понятно, что это глобальные переменные, то можно было бы это понять, но без этого уточнения выглядит скриншот очень странным с точки зрения реализации.
Вопрос по переменным в том, что непонятно зачем они там. Если бы было понятно, что это глобальные переменные, то можно было бы это понять, но без этого уточнения выглядит скриншот очень странным с точки зрения реализации.
0
Еще раз здравствуйте.
1. Проблема с парсингом может быть решена несколькими способами, в том числе и Вашим. В некоторых случаях мы используем вариант, описанный Вами, в других — который описан в статье. Сказать что проще, что сложнее однозначно нельзя.
2. Действительно в статье упущен момент, что на скриншоте приведен готовый fieldset, универсальный для большинства сетевых событий. Но задача была показать в первую очередь факт срабатывания, основную смысловую нагрузку в этом случае несет следующих скриншот.
1. Проблема с парсингом может быть решена несколькими способами, в том числе и Вашим. В некоторых случаях мы используем вариант, описанный Вами, в других — который описан в статье. Сказать что проще, что сложнее однозначно нельзя.
2. Действительно в статье упущен момент, что на скриншоте приведен готовый fieldset, универсальный для большинства сетевых событий. Но задача была показать в первую очередь факт срабатывания, основную смысловую нагрузку в этом случае несет следующих скриншот.
0
Sign up to leave a comment.
JSOC: как готовить инциденты