Соответствие стандартам и политикам в сканерах уязвимостей и SIEM

    Английский термин compliance означает соответствие одному из высокоуровневых стандартов (таким как SOX, PCI DSS, Basel II, GLBA). Проводить проверку на соответствие этим документам необходимо для того, чтобы определить, насколько хорошо в вашей организации соблюдаются требования, описанные данными стандартами (разрешенная длина паролей, наличие внутренних регламентов и политик, время устранения уязвимостей и т. п.).

    Помимо международных стандартов существуют их отечественные аналоги, корпоративные политики и требования NIST.Проводить оценку соответствия этим документам также необходимо. Стандарты содержат наборы требований: выполнение всех требований стандарта фактически означает соответствие ему. Пример отдельного требования: «Должен иметься дисциплинарный процесс для служащих, которые произвели нарушение защиты» (ИСО/МЭК 2005 A.8.2.3).

    Проводить проверку на соответствие стандартам необходимо не только для отчетности: чем больше требований выполняется, тем выше уровень защищенности и тем ниже риски финансовых потерь при возникновении угроз. Очевидно, что обеспечивать соответствие стандартам необходимо постоянно и непрерывно — иначе при очередной аудиторской проверке придется потратить кучу сил и нервов на поспешное внесение изменений в конфигурации и инфраструктуру в соответствии с требованиями.

    Как проводить проверку соответствия стандарту


    На курсах аудиторов по ISO 27001 мне довелось встретить сотрудников департамента ИБ одной организации, которые при проверке соответствия использовали стандарт 27001, но оценивали соответствие и просчитывали риски в экселевской таблице. Зрелище не для слабонервных, признаюсь вам.

    Конечно, можно проверять соответствие подобным образов, выписывая требования стандарта на лист бумаги или в Excel. Можно воспользоваться специальным ПО, в котором сотрудники, ответственные за те или иные аспекты безопасности, будут отвечать на типовые вопросы: «Да, нет, не знаю». Но насколько достоверной будет полученная информация? Уверены ли вы, что администратор домена действительно установил минимальную длину паролей равную 7 символам? А вы действительно уверены, что этот администратор не сделал фейковый скриншот, а потом не вернул настройки групповых политик в состояние, которое он (!) считает необходимым? Часть требований можно проверить только с помощью опроса сотрудников, но выполнение остальных требований вполне можно проверять автоматизированными средствами.

    Типы требований


    Требования делятся на технические и нетехнические. К техническим требованиям относится та информация, которую можно проверить с помощью средств автоматизации (выполнив команду в консоли, парсером по файлу конфигурации, через параметр реестра).

    Приведу простой пример технического требования, упоминающегося в большинстве стандартов: PCI DSS 8.5.10 “Require a minimum password length of at least seven characters”, PCI DSS Requirements 5.1. “Deploy anti-virus software on all systems сommonly affected by malicious software (particularly personal computers and servers)”.

    Нетехнические требования, соответственно, проверить с помощью средств автоматизации не получится. Пример такого требования — упомянутый выше ИСО/МЭК 2005 A.8.2.3.

    Ни один стандарт нельзя полностью описать с помощью одних лишь технических требований. При отсутствии средств автоматизации мы можем их все считать нетехническими. Появляется возможность автоматической проверки требования — оно становится техническим. Чем больше таких требований мы сможем проанализировать (проверить выполнение их в системе), тем оперативнее можно будет снижать риски, устраняя несоответствия.

    Необходимо сразу пояснить, что процесс проверки соответствия вообще принято делить на compliance (без префикса standard; имеется в виду соответствие высокоуровневым стандартам по умолчанию), regulatory compliance (требования надзорных органов, к примеру СТО БР ИББС) и policy compliance (соответствие политикам, будь то корпоративная политика или NIST). Все эти термины в рамках данной статьи мы будем понимать как «проверку на соответствие стандартам (политикам)».

    От стандартов к политикам


    Что делать, если вам не нужны никакие стандарты, но хочется контролировать соблюдение политик ИБ?

    Понятие «проверка соответствия» применимо не только для высокоуровневых стандартов (ISO, руководства NIST, SOX, Basel II) и руководств NIST, но и для внутренних политик компаний. Многие требования корпоративных политик состоят из требований стандартов. Это означает, что можно выделить технические требования из стандартов, описанных в вашей корпоративной политике ИБ, объединить их в политику и отслеживать уже ее.

    Другой вопрос — как автоматизировать процесс получения и обработки требований для оценки соответствия стандарту? Ответ прост: такими средствами автоматизации, как сканеры уязвимостей, системы класса CMS (compliance management system), SIEM или в крайнем случае самописными сценариями.

    Как это работает?


    Для CMS и сканеров уязвимостей в задании на сканирование соответствия определенному стандарту определяются IP-адреса информационных систем организации. Затем производится сканирование системы для определения соответствия требованиям выбранного стандарта (как правило, при этом сканер получает все доступные данные), после чего осуществляется оценка того, все ли технические требования данного стандарта выполняются на выбранных активах.



    Как правило, в системе существует список доступных шаблонов стандартов с предопределенным набором требований, которые можно выбрать для оценки соответствия. Если же чего-то не хватает, то можно докупить у производителя сканера лицензии на отсутствующие стандарты или разработать свой собственный.

    Разработка собственного стандарта


    В сканерах уязвимостей с функцией проверки соответствия стандартам есть возможность создать свой стандарт с нуля или на базе уже имеющегося. В процессе создания можно переопределить значения, которые проверяются в рамках требований или добавить собственные.

    Добавление собственных требований возможно благодаря гибким механизмам проверок. В каждой системе требования состоят из одной или нескольких проверок. Как правило, проверки эти реализованы с помощью нескольких сценариев с различными методами и транспортами (WMI, RPC и т. п.). У McAfee VM, например, часть сценариев, хранящихся в базе данных, выглядит как на рис. ниже.



    Однако нам нет необходимости копаться в базе данных и вообще знать — какой сценарий что проверяет. Как правило, производители ПО предоставляют графический интерфейс для работы с требованиями. В свой новый стандарт или политику мы можем включить практически любые технические требования и переопределить значения их параметров.



    Если же такого интерфейса нет, то должна по крайней мере быть доступна документация по созданию собственного стандарта (например, в формате XML). Немного усилий — и уникальный стандарт, отражающий требования к ИБ в конкретной организации, готов.

    SIEM


    Теперь поговорим о SIEM. Некоторые понятия, связанные с подобными системами, мы рассматривали ранее в нашем блоге:

    1) Что такое SIEM http://blog.ptsecurity.ru/2012/10/siem.html
    2) Для чего нужна интеграция SIEM и сканера уязвимостей http://blog.ptsecurity.ru/2012/10/siem_1.html
    3) Что такое сигнатурные методы корреляции http://blog.ptsecurity.ru/2012/10/siem_17.html
    4) Как управлять инцидентами ИБ http://blog.ptsecurity.ru/2012/11/blog-post.html

    Теперь давайте зададимся вопросом, зачем в принципе в SIEM нужна проверка соответствия. Что под этим процессом понимается в SIEM? И почему бы не использовать для такой проверки только сканеры уязвимости и compliance management systems?

    Во-первых, в стандартах существуют требования по журналированию части событий, связанных с учетными записями, доступом к объектам, изменения групповых политик и т. п. Контролировать выполнение этих требований тоже необходимо, поскольку есть возможность проверить, поступают ли эти типы событий в наш SIEM.

    Во-вторых, в отличие от различных сканеров, SIEM-системы непрерывно получают информацию, которую можно использовать для динамической оценки соответствия в режиме реального времени. Как быстро вы узнаете об отключении антивирусной защиты на вашем сервере или изменении доменной политики? В подобных ситуациях запуск сканера, как правило, нагружает сеть и информационные системы, поскольку процесс проверки соответствия стандарту (например, PCI DSS) часто влечет за собой и сканирование на уязвимости (а это огромная нагрузка, которая может «уронить» вашу производственную систему).

    SIEM в данном случае выступает пассивным источником данных о соответствии тому или иному стандарту, получаемых в режиме реального времени: снимается проблема менеджмента журналов. В то же время у нас есть возможность на основе поступающих данных о различных событиях определять, что именно приводит к несоответствию. Далее проверяется соответствие определенному требованию выбранного стандарта, и в случае обнаружения несоответствия администратору информационной системы отправляется уведомление.

    Кроме того, если в системе осуществляется инцидент-менеджмент, то ответственному сотруднику будет также поставлена задача по устранению несоответствия.

    Звучит красиво, не правда ли? Теперь вернемся к нашим SIEM-системам и посмотрим, каким образом они, собственно, оценивают соответствие тому или иному стандарту.

    Высокоуровневые стандарты предполагают сбор и хранение информации об определенных событиях (указаны в таблице).



    С учетом отдельных стандартов получается следующая картина.



    Повторю еще раз: акцент здесь делается на сборе и хранении. Мы не увидим ничего похожего на «анализ», «аудит полученных данных» (не путать с «аудитом входа в систему», это обычные данные из журналов).

    Если вы ожидаете, что результатом контроля соответствия стандарту с использованием SIEM станет сообщение вида «Установлена минимальная длина пароля» с указанием соответствующего или не соответствующего требования, — вы, к сожалению, ошибаетесь.

    После запуска проверки на соответствие любому высокоуровневому стандарту из списка доступных в SIEM-системе в отчете вы получите только лишь список событий и систем с разбивкой по требованиям или (в лучшем случае) отчет по событиям в рамках этого требования (например, Data flows).





    Отсюда можно сделать вывод, что SIEM-системы не предназначены для оценки соответствия, а нужны как техническое средство для соблюдения отдельных требований стандартов по сбору и хранению событий и имеют лишь функциональность track@report.

    Конечно, есть и исключения, но их немного. Некоторые вендоры пытаются частично извлечь из поступающих событий полезную информацию, влияющую на соответствие стандартам. В этом случае требования соотносятся с правилами корреляции SIEM. При этом одному требованию соответствует несколько правил. Это объясняется тем, что конкретный факт (например, изменение минимальной длины пароля в доменной политике) может включать в себя много событий от разных источников данных, да и содержание самого события может быть разным.

    Кроме того, в журнале событий каждого источника данных конкретное событие может быть описано различными служебными словами, с разными event_id.



    Однако выполнение проверки соответствия подобным образом требует слишком большого количества ресурсов, поэтому разработчики SIEM отказываются от этой затеи.

    Почему же возникли трудности в реализации полноценного анализа на соответствие? Кратко рассмотрим основные причины.

    Причина первая. В SIEM отсутствует понятие объекта. Тут можно вспомнить метод корреляции “MBR model based reasoning”, описанный в одной из предыдущих статей. С помощью данного метода, к примеру, можно было бы описать состояние объекта, приводящее к несоответствию.


    В модели SIEM хранятся события, категории и классы событий, статистика. Однако там отсутствуют состояния объектов или активов (хотя этого понятия для SIEM и не существует).

    Причина вторая. В SIEM-системах большинства производителей события не нормализуются (не приводятся к одному стандартизированному виду), поэтому нужно составлять большое количество логических правил корреляции. Это, в свою очередь, приводит к нерациональности составления полноценного standard compliance.

    Почему так происходит? Все производители стремятся выполнить требование NIST 800-92 («Original event is preserved and no data is changed during normalization») и, дабы обеспечить неизменность исходных событий, хранят их формате RAW.

    Что же делать? Как вариант — применять стандарт CEE (http://cee.mitre.org). Это позволит стандартизировать события без противоречия с NIST 800-92.

    В SIEM не получится описать все технические требования стандартов по одной простой причине: значения требований не передаются в событиях от источников. Соответственно, SIEM без дополнительного функционала сканера в SIEM-агенте эти значения не получит. Однако, тренд сейчас — использование безагентных технологий. Несмотря ни на что с помощью SIEM можно отследить большую часть состояния требований в режиме реального времени. Разработчикам SIEM нужно лишь сделать шаг для исправления ошибок.

    Надеюсь, в этой статье мне удалось развеять миф о проверке соответствия стандартам в SIEM-системах, а также дать представление о понятиях standard compliance, policy compliance, regulatory compliance.

    До встречи в новых публикациях! Ждем ваших вопросов и замечаний в комментариях.

    Автор: Олеся Шелестова, Исследовательский центр Positive Research.
    Метки:
    Positive Technologies 176,24
    Компания
    Поделиться публикацией
    Комментарии 14
    • 0
      Насчитал 7 пользователей SIEM, расскажите как оно, почувствовали пользу от внедрения? Используете ли SIEM на полную катушку?
      Долго ли настраивали корреляционные механизмы? Кто этим занимается в рамках зацикленной модели PDCA? :)
      • +1
        Проводить проверку на соответствие стандартам необходимо не только для отчетности: чем больше требований выполняется, тем выше уровень защищенности и тем ниже риски финансовых потерь при возникновении угроз. Очевидно, что обеспечивать соответствие стандартам необходимо постоянно и непрерывно — иначе при очередной аудиторской проверке придется потратить кучу сил и нервов на поспешное внесение изменений в конфигурации и инфраструктуру в соответствии с требованиями.


        так для чего всё-таки контролируем выполнение требований — для повышения уровня реальной защищенности или для защиты от аудиторской проверки?
        • 0
          Добрый день!
          Общая цель — защищенность. Аудиторские проверки на соответствие стандартам не у всех проводятся. Если нет требований отраслевых или компания не прошла сертификацию по ISO, то зачем аудиторские проверки? Так считаю многие, отодвигая все стандарты в сторону и начиная изобретать велосипед в виде внутренних бумажных политик без контроля их соблюдения. Максимум что делают в подобном лучшем случае — заказывают сторонний аудит ИБ. А можно взять за основу политик контроли, указанные в стандартах, расширить их и контролировать их соблюдение. Согласитесь, что часть требований стандартов — это азы информационной безопасности, которые необходимо соблюдать и контролировать. Если они не учтены — то о какой безопасности может идти речь?
          • 0
            Про контроль соблюдения политики.

            Я вот никак не пойму, про какие вы сети говорите?
            Про дикую сетку, из отдельных рабочих станций, в которой рядовые работнички, все под админами и творят что хотят? Мы им бумажку кидаем, давайте ребята, делайте сложные пароли. Ребята плюют с высокой колокольни на ваши бумажки и ставят пароли по своему. Тогда мы внедряем навороченный SIEM, что бы он опрашивал всю тысячу наших рабочих машин в дикой сетке и выявлял непокорных. Публично караем за неповиновение.

            Или все таки сетка организованна в домен, где настройки спускаются централизованно. И работничек может сделать только то, что ему позволено. И что мне покажет тогда SIEM, чего я и так не буду знать?
            • 0
              То есть, вы с помощью политик домена контролируете «все и вся» и при этом:
              — пользователь не может загрузиться с livecd\usb и нарушить работу вашей инфраструктуры
              — пользователь не может повысить привилегии
              — нельзя получить административный аккаунт доменного админа или к какой либо информационной системе
              — пользователь не может несанкционированно запустить софт (в т.ч. portable)
              — о появлении вируса\атаки\угрозы\утечки вы в режиме реального времени узнаете и отреагируете (!) и все будет документировано?!
              — вы сможете предоставить юрилически значимые журналы событий когда к вам придут и скажут что ваша компания ддосит кремлинру?
              — вы сможете сказать кто и когда изменил настройки на сервере\рабочей станции\базе данных\роутере\файерволле?
              Если все «да» и вы это сделали с помощью домена — честь и благодать Вам.
              • 0
                Ну Вот пошла конкретика, давайте подискутируем.

                Самое главное что у нас в наш рыночный век? Самое главное у нас это Бизнес. А Бизнесу интересна не политика ИБ как самоцель, а как не попасть на «бабки».

                Рассматривая в нашем примере рабочую станцию, как структурную единицу, зададимся вопросом, как рядовой работничек может поставить бизнес «на бабки». И уже от этого пляшем.

                Первое, основное и самое очевидно, несомненно слив информации работника с определенным доступом, к конкурентам, SIEM тут никаким боком ибо задача эта для DLP системы.
                Вот по сути и все… Более ничем нам рабочая станция не интересна. Нарушение функционирования рядовой рабочей станции не критично для Бизнеса.

                А отличии от других активов, например серверов, на которых крутятся значимые базы. Вот на них и плотно ставится контроль. В том числе на политики, которые централизованно спускаются, с этих серверов.

                Далее остальные технические нюансы.

                То есть, вы с помощью политик домена контролируете «все и вся» и при этом:
                — пользователь не может повысить привилегии
                — пользователь не может несанкционированно запустить софт (в т.ч. portable)
                — нельзя получить административный аккаунт доменного админа или к какой либо информационной системе.


                Накатывается SRP, пользователь сидит без админских прав. Средний навык рядового пользователя по хакингу систем колышется около 0 уровня. Физически Крутых хакеров со стороны не подпускает к компьютерам забор с колючкой, СКУД и мордовороты на воротах, виртуально – трутся на задворках корпоративного FW.

                — пользователь не может загрузиться с livecd\usb и нарушить работу вашей инфраструктуры


                Может при большом желании конечно. Как мне поможет в этом случае SIEM, что-то я не представляю.
                Вот в агентской части DLP было бы интересно иметь факт определения загрузки не «родной» ОС. Ибо так можно документики в обход агента спионерить.
                Загрузка бэктрека и долбежка сплоитами и сканами определяется со стороны атакуемых серверов, как критичного актива.
                Хотя если работник чисто из злобности решил завалить комп соседа, а не просто дать ему в морду. Ну это наверно бывает, запишем в неизбежные риски.

                — о появлении вируса\атаки\угрозы\утечки вы в режиме реального времени узнаете и отреагируете (!) и все будет документировано?!
                — вы сможете предоставить юридически значимые журналы событий когда к вам придут и скажут что ваша компания ддосит кремлинру?


                А что журнал событий обязательно извлекать из SIEM? Он спокойно себе пишется на серверах, бакапится по расписанию.
                В случае актуальной угрозы придет алерт на мыло от IDS/Антивирусной защиты/Настроенной на критичных серверах Системы событий Windows/Еще пары забавных штук.
                Грамотно закрученные гайки, позволяют минимизировать количество этих сообщений.

                — вы сможете сказать кто и когда изменил настройки на сервере\рабочей станции\базе данных\роутере\файерволле?


                Логи сохраняются и бакапятся. В реальном времени мониторить, как я говорил, всю инфрастуктуру не нужно. Нужно разделять ее по критичности для бизнеса. Критичные роутеры мониторятся в обязательном порядке.
                Про гайки я уже говорил. Например, консоль роутера доступна не всей сети, а специально выделенным машинам.

                Если все «да» и вы это сделали с помощью домена — честь и благодать Вам.


                Сделано без SIEM, а вот где реально без SIEM не обойтись?
                • 0
                  Данная статья не позиционировалась как «купите SIEM, без него нельзя». Можно. Но только когда инфраструктура небольших размеров. С ростом, появляется множество задач по контролю и соблюдению. Политики мало написать, «закрутить гайки» и спокойно пить кофе. Необходимо контролировать их соблюдение. Оправдание «Средний навык рядового пользователя по хакингу систем колышется около 0 уровня» нужно держать в себе и в одном из пунктов модели нарушителя.
                  Логи бекапятся, ок. Но с какой переодичностью? Достаточной для расследования инцидента? А можно быть уверенной что все необходимые события там будут? Может кто то случайно назначит GPO и там будет лишь пустота. Гарантируется ли юридическая значимость этих забекапленных логов? А если будет многомиллионная транзакция?! Вы сможете привести в суде доказательства, что это действительно те самы логи с того самого сервера, а не фальсифицированные доказательства?!.. Можно их перенаправлять и на Syslog. Но опять же — где кдц. Да и не все источники могут поддерживать tcp syslog — в противном случае, часть событий при потоке выше 5-7к eps syslog udp скорее всего будут потеряны (по результатам тестирования).
                  SIEM не панацея от 0-day и всех-всех угроз. SIEM — средство автоматизации.
                  SIEM автоматизирует монотонную работу с журналами событий, выстраивает процессы инцидент-менеджмента, приоритезируя инциденты и фокусируя внимание подразделений ИТ и ИБ на важных для бизнеса. Дополняет процессы управления политиками и комплайнса, управления конфигурациями…
                  Приходите на рускрипто-2013, у меня как раз будет выступление и пообщаемся в колуарах. Переубеждать я не намеряна, просто расскажу :)
                  • 0
                    Переубеждать не надо, вещь эта нужная и интересная несомненно. Хочется понять, насколько нужная. Насколько она стоит своих затрат.

                    Вот Вашим словам.

                    Повторю еще раз: акцент здесь делается на сборе и хранении. Мы не увидим ничего похожего на «анализ», «аудит полученных данных» (не путать с «аудитом входа в систему», это обычные данные из журналов).

                    Если вы ожидаете, что результатом контроля соответствия стандарту с использованием SIEM станет сообщение вида «Установлена минимальная длина пароля» с указанием соответствующего или не соответствующего требования, — вы, к сожалению, ошибаетесь. Отсюда можно сделать вывод, что SIEM-системы не предназначены для оценки соответствия, а нужны как техническое средство для соблюдения отдельных требований стандартов по сбору и хранению событий и имеют лишь функциональность track@report.


                    Акцент на сборе и хранении. Даже по другому — Юридически значимом сборе и хранении, чтобы опровергнуть многомиллионные транзакции, чтобы следить за кучей серверов, которые все значимы для Бизнеса, собирать с них не убиваемый лог, которым можно потрясти в суде.

                    Получается, эта тема востребована в основном банковским сектором?

                    А остальным? Которым не надо трясти бакапами в суде? Остальным по идее, логично было бы надеяться на автоматизацию рутины.

                    SIEM автоматизирует монотонную работу с журналами событий, выстраивает процессы инцидент-менеджмента, приоритезируя инциденты и фокусируя внимание подразделений ИТ и ИБ на важных для бизнеса.


                    И тут опять всплывает из вашей статьи, что у сегодняшних SIEM «акцент здесь делается на сборе и хранении».

                    Если он автоматизирует, то каким, образом, ведь Вы пишете.

                    " в журнале событий каждого источника данных конкретное событие может быть описано различными служебными словами, с разными event_id., выполнение проверки соответствия подобным образом требует слишком большого количества ресурсов, поэтому разработчики SIEM отказываются от этой затеи."

                    Что в результате приводит опять только лишь, к Юридически значимому логу, без невозможности автоматического анализа.
                    • 0
                      Не только банковский сектор. Почти в каждой организации есть банк-клиенты. Представьте что с компьютера бухгалтера переводят максимальную сумму со счета в оффшор. И не важно кто это сделал — троян, сам главный бухгалтер или новая сотрудница с нулевыми знаниями в хакинге.
                      Представьте, что кто то заимел халявную ноду и поднял VPS. Или сливает по 10-20 литров бензина за смену когда температура в хранилище нагревается до определенного значения. Или когда запускаются процессы на компьютере генерального директора в его отсутствие и отсутствии VPN к его компьютеру.
                      Когда события собраны в единое хранилище со всех источников (либо таких хранилищ несколько) по ним можно делать корреляцию и определять взаимосвязи, отслеживать тенденции. Открываем дашбоард, и видим всплески трафика на порт, видим кучу неуспешных попыток входа, а затем успешную. Без SIEM эти факты еще предстоит выяснить, после того как мы узнаем об утечке или удалении, к примеру, всей корпоративной информации на файловом хранилище. Или нанимать кучу людей которые будут мониторить логи. Как часто можно смотреть те же журналы событий на VPN? а если Катя, которая все время коннектилась с акадо-москва вдруг залезла на vpn с тайваня? SIEM это увидит, сгенерирует инцидент. причем это должно быть не просто письмо в электронную почту (ибо через неделю никто не будет читать их, или сотрудник заболеет, или сработает человеческий фактор и он попросту пропустит событие при просмотре, потому что клубился всю ночь.
                      Логи DLP и антивирусного ПО тоже надо смотреть. И конфигурации с логов читать.В противном случае — насколько будет уверено руководство компании что месяц назад админ-ИБ-смотрящий-DLP не взял шоколадку и пропустил за это событие ака «Ваня отослал на какой-то ящик список ваших сотрудников». Антивирусное ПО — да, можно в ПО смотреть ситуацию. Но очень сложно организовать работу, при которой во всей инфраструктуре установлено ПО, обновлено до актуальных баз и с правильными настройками согласно ваших политик и инструкций.
                      Для ИТ будет лучше поскорее узнать о том что отказал диск в рейде или сервис застопорился. Не по звонку от рассерженных пользователей, которые потеряли часть данных. Да, можно и скриптами. Их не один десяток придется написать. И не одну сотню. Уверены что ИТ специалист среагирует на этот алерт? Или все же лучше зарегистрировать инцидент с опеределенным приоритетом, фиксированными сроками решения и эскалацией в случае его просрочки?
                      Это все ИТ-Ибшные части. Сейчас все SIEM стремятся приоритезировать инциденты по результатам корреляций и с учетом рисков, исходя из ценности актива, его участия в бизнес-процессах и т.д. В итоге, вы сможете увидеть на какие бизнес-процессы влияют те или иные события.И что будет если остановить сервис\удалить пользователя\не закрыть уязвимость.
                      Источников много. Угроз и векторов атак еще больше. Нельзя полагаться на «поставил и забыл».
                      • 0
                        Или когда запускаются процессы на компьютере генерального директора в его отсутствие и отсутствии VPN к его компьютеру.
                        Когда события собраны в единое хранилище со всех источников (либо таких хранилищ несколько) по ним можно делать корреляцию и определять взаимосвязи, отслеживать тенденции. Открываем дашбоард, и видим всплески трафика на порт, видим кучу неуспешных попыток входа, а затем успешную.


                        Алгоритм корреляции пишет оператор SIEM? Или SIEM это искусственный интеллект (свершилось!), который сам решает что важно, а что нет?
                        • 0
                          SIEM не равно продукт из коробки. Есть предзаданные правила корреляции. Правила корреляции пишутся дополнительно при интеграции. Правила дополняются при пентестах, аудитах и т.п. (PDCA).
                          Простому оператору не стоит доверять писать правила корреляции. Вообще, чем больше правил корреляции — тем больше нагрузка на сервер (см. мои статьи в цикле по SIEM. Счетчики и триггеры висят в памяти)
                          Маской описывается кейс запуска процессов или сетевых коннектах при отсутствии сотрудника (интеграция агента и скуда — уже в практике давно применяется, но реализация возможна не на всех сиемах).
                          Статистика дашбордов репрезентативно показывает всплески от baseline.
                          • 0
                            Да вот меня смутило про отлов перевода в офшор… А если мелкими суммами накидать? А если оформлять на подставных людей?
                            www.securitylab.ru/news/438210.php
                            Сразу мысль, про ИИ который бдит, его еще к камерам подключить, он будет по выражению лица определять плохишей.

                            Есть еще вопрос.
                            Вот представим сеть из 1000 машин, куча роутеров, скуд, идем по вашему принципу собираем в SIEM все возможные события, гребем лопатой по максимуму, а то мало ли что. Угроз и векторов полно. Отслеживаем все, вплоть до смарта хардов, харды ведь тоже надо менять вовремя.

                            Сможет ли отдел ИБ разгребать все, что ему начнет валить SIEM, чтобы не по факту карать, а заранее предотвращать.

                            Без SIEM эти факты еще предстоит выяснить, после того как мы узнаем об утечке или удалении, к примеру, всей корпоративной информации на файловом хранилище.


                            Вот сработка SIEM, по скуду человека нет, а машина активна. Отряд ИБ несется на крыльях ночи, в удаленный офис, а там баба Маня случайно шваброй задела кнопку Повер.
                            Вот с нового ip попер какой то непонятный VPN трафик, карательный отряд подрывается, но оказывается это dhcp сменил адрес старой машины, на новый.
                            Вот какой то непонятный траф стал генериться с компа генерального директора, все садятся на измену, в итоге выясняется, что это гендир просто решил зарубиться в контру по инету.
                            Сколько будет вот такого ложняка, при том количестве информации, что будет получать SIEM с 1000 хостов?
                            Может имеет смысл к отряду операторов, пишуших корреляции, внедрить отдельный отряд реагирования на отклонения от baseline?
                            • +1
                              чтобы не по факту карать, а заранее предотвращать.

                              В большинстве случаев-таки именно по факту карать. С доказательной базой, которой не только в суде трясти, но и для внутренних документов. Ну или чтобы пользователю пальчиком погрозить «Вася, не надо так делать!» — но если инфидент есть в SIEM, то он уже произошел.
                              Другой вопрос, что, может быть инцидент не имел продолжения ввиду того, что сработала какая-то другая система ИБ
                              • 0
                                Вам надо статью написать, что-нибудь вроде SIEM глазами практика. У меня много вопросов отпало только после ваших ответов в личке.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое