Comments 14
Насчитал 7 пользователей SIEM, расскажите как оно, почувствовали пользу от внедрения? Используете ли SIEM на полную катушку?
Долго ли настраивали корреляционные механизмы? Кто этим занимается в рамках зацикленной модели PDCA? :)
Долго ли настраивали корреляционные механизмы? Кто этим занимается в рамках зацикленной модели PDCA? :)
Проводить проверку на соответствие стандартам необходимо не только для отчетности: чем больше требований выполняется, тем выше уровень защищенности и тем ниже риски финансовых потерь при возникновении угроз. Очевидно, что обеспечивать соответствие стандартам необходимо постоянно и непрерывно — иначе при очередной аудиторской проверке придется потратить кучу сил и нервов на поспешное внесение изменений в конфигурации и инфраструктуру в соответствии с требованиями.
так для чего всё-таки контролируем выполнение требований — для повышения уровня реальной защищенности или для защиты от аудиторской проверки?
Добрый день!
Общая цель — защищенность. Аудиторские проверки на соответствие стандартам не у всех проводятся. Если нет требований отраслевых или компания не прошла сертификацию по ISO, то зачем аудиторские проверки? Так считаю многие, отодвигая все стандарты в сторону и начиная изобретать велосипед в виде внутренних бумажных политик без контроля их соблюдения. Максимум что делают в подобном лучшем случае — заказывают сторонний аудит ИБ. А можно взять за основу политик контроли, указанные в стандартах, расширить их и контролировать их соблюдение. Согласитесь, что часть требований стандартов — это азы информационной безопасности, которые необходимо соблюдать и контролировать. Если они не учтены — то о какой безопасности может идти речь?
Общая цель — защищенность. Аудиторские проверки на соответствие стандартам не у всех проводятся. Если нет требований отраслевых или компания не прошла сертификацию по ISO, то зачем аудиторские проверки? Так считаю многие, отодвигая все стандарты в сторону и начиная изобретать велосипед в виде внутренних бумажных политик без контроля их соблюдения. Максимум что делают в подобном лучшем случае — заказывают сторонний аудит ИБ. А можно взять за основу политик контроли, указанные в стандартах, расширить их и контролировать их соблюдение. Согласитесь, что часть требований стандартов — это азы информационной безопасности, которые необходимо соблюдать и контролировать. Если они не учтены — то о какой безопасности может идти речь?
Про контроль соблюдения политики.
Я вот никак не пойму, про какие вы сети говорите?
Про дикую сетку, из отдельных рабочих станций, в которой рядовые работнички, все под админами и творят что хотят? Мы им бумажку кидаем, давайте ребята, делайте сложные пароли. Ребята плюют с высокой колокольни на ваши бумажки и ставят пароли по своему. Тогда мы внедряем навороченный SIEM, что бы он опрашивал всю тысячу наших рабочих машин в дикой сетке и выявлял непокорных. Публично караем за неповиновение.
Или все таки сетка организованна в домен, где настройки спускаются централизованно. И работничек может сделать только то, что ему позволено. И что мне покажет тогда SIEM, чего я и так не буду знать?
Я вот никак не пойму, про какие вы сети говорите?
Про дикую сетку, из отдельных рабочих станций, в которой рядовые работнички, все под админами и творят что хотят? Мы им бумажку кидаем, давайте ребята, делайте сложные пароли. Ребята плюют с высокой колокольни на ваши бумажки и ставят пароли по своему. Тогда мы внедряем навороченный SIEM, что бы он опрашивал всю тысячу наших рабочих машин в дикой сетке и выявлял непокорных. Публично караем за неповиновение.
Или все таки сетка организованна в домен, где настройки спускаются централизованно. И работничек может сделать только то, что ему позволено. И что мне покажет тогда SIEM, чего я и так не буду знать?
То есть, вы с помощью политик домена контролируете «все и вся» и при этом:
— пользователь не может загрузиться с livecd\usb и нарушить работу вашей инфраструктуры
— пользователь не может повысить привилегии
— нельзя получить административный аккаунт доменного админа или к какой либо информационной системе
— пользователь не может несанкционированно запустить софт (в т.ч. portable)
— о появлении вируса\атаки\угрозы\утечки вы в режиме реального времени узнаете и отреагируете (!) и все будет документировано?!
— вы сможете предоставить юрилически значимые журналы событий когда к вам придут и скажут что ваша компания ддосит кремлинру?
— вы сможете сказать кто и когда изменил настройки на сервере\рабочей станции\базе данных\роутере\файерволле?
Если все «да» и вы это сделали с помощью домена — честь и благодать Вам.
— пользователь не может загрузиться с livecd\usb и нарушить работу вашей инфраструктуры
— пользователь не может повысить привилегии
— нельзя получить административный аккаунт доменного админа или к какой либо информационной системе
— пользователь не может несанкционированно запустить софт (в т.ч. portable)
— о появлении вируса\атаки\угрозы\утечки вы в режиме реального времени узнаете и отреагируете (!) и все будет документировано?!
— вы сможете предоставить юрилически значимые журналы событий когда к вам придут и скажут что ваша компания ддосит кремлинру?
— вы сможете сказать кто и когда изменил настройки на сервере\рабочей станции\базе данных\роутере\файерволле?
Если все «да» и вы это сделали с помощью домена — честь и благодать Вам.
Ну Вот пошла конкретика, давайте подискутируем.
Самое главное что у нас в наш рыночный век? Самое главное у нас это Бизнес. А Бизнесу интересна не политика ИБ как самоцель, а как не попасть на «бабки».
Рассматривая в нашем примере рабочую станцию, как структурную единицу, зададимся вопросом, как рядовой работничек может поставить бизнес «на бабки». И уже от этого пляшем.
Первое, основное и самое очевидно, несомненно слив информации работника с определенным доступом, к конкурентам, SIEM тут никаким боком ибо задача эта для DLP системы.
Вот по сути и все… Более ничем нам рабочая станция не интересна. Нарушение функционирования рядовой рабочей станции не критично для Бизнеса.
А отличии от других активов, например серверов, на которых крутятся значимые базы. Вот на них и плотно ставится контроль. В том числе на политики, которые централизованно спускаются, с этих серверов.
Далее остальные технические нюансы.
Накатывается SRP, пользователь сидит без админских прав. Средний навык рядового пользователя по хакингу систем колышется около 0 уровня. Физически Крутых хакеров со стороны не подпускает к компьютерам забор с колючкой, СКУД и мордовороты на воротах, виртуально – трутся на задворках корпоративного FW.
Может при большом желании конечно. Как мне поможет в этом случае SIEM, что-то я не представляю.
Вот в агентской части DLP было бы интересно иметь факт определения загрузки не «родной» ОС. Ибо так можно документики в обход агента спионерить.
Загрузка бэктрека и долбежка сплоитами и сканами определяется со стороны атакуемых серверов, как критичного актива.
Хотя если работник чисто из злобности решил завалить комп соседа, а не просто дать ему в морду. Ну это наверно бывает, запишем в неизбежные риски.
А что журнал событий обязательно извлекать из SIEM? Он спокойно себе пишется на серверах, бакапится по расписанию.
В случае актуальной угрозы придет алерт на мыло от IDS/Антивирусной защиты/Настроенной на критичных серверах Системы событий Windows/Еще пары забавных штук.
Грамотно закрученные гайки, позволяют минимизировать количество этих сообщений.
Логи сохраняются и бакапятся. В реальном времени мониторить, как я говорил, всю инфрастуктуру не нужно. Нужно разделять ее по критичности для бизнеса. Критичные роутеры мониторятся в обязательном порядке.
Про гайки я уже говорил. Например, консоль роутера доступна не всей сети, а специально выделенным машинам.
Сделано без SIEM, а вот где реально без SIEM не обойтись?
Самое главное что у нас в наш рыночный век? Самое главное у нас это Бизнес. А Бизнесу интересна не политика ИБ как самоцель, а как не попасть на «бабки».
Рассматривая в нашем примере рабочую станцию, как структурную единицу, зададимся вопросом, как рядовой работничек может поставить бизнес «на бабки». И уже от этого пляшем.
Первое, основное и самое очевидно, несомненно слив информации работника с определенным доступом, к конкурентам, SIEM тут никаким боком ибо задача эта для DLP системы.
Вот по сути и все… Более ничем нам рабочая станция не интересна. Нарушение функционирования рядовой рабочей станции не критично для Бизнеса.
А отличии от других активов, например серверов, на которых крутятся значимые базы. Вот на них и плотно ставится контроль. В том числе на политики, которые централизованно спускаются, с этих серверов.
Далее остальные технические нюансы.
То есть, вы с помощью политик домена контролируете «все и вся» и при этом:
— пользователь не может повысить привилегии
— пользователь не может несанкционированно запустить софт (в т.ч. portable)
— нельзя получить административный аккаунт доменного админа или к какой либо информационной системе.
Накатывается SRP, пользователь сидит без админских прав. Средний навык рядового пользователя по хакингу систем колышется около 0 уровня. Физически Крутых хакеров со стороны не подпускает к компьютерам забор с колючкой, СКУД и мордовороты на воротах, виртуально – трутся на задворках корпоративного FW.
— пользователь не может загрузиться с livecd\usb и нарушить работу вашей инфраструктуры
Может при большом желании конечно. Как мне поможет в этом случае SIEM, что-то я не представляю.
Вот в агентской части DLP было бы интересно иметь факт определения загрузки не «родной» ОС. Ибо так можно документики в обход агента спионерить.
Загрузка бэктрека и долбежка сплоитами и сканами определяется со стороны атакуемых серверов, как критичного актива.
Хотя если работник чисто из злобности решил завалить комп соседа, а не просто дать ему в морду. Ну это наверно бывает, запишем в неизбежные риски.
— о появлении вируса\атаки\угрозы\утечки вы в режиме реального времени узнаете и отреагируете (!) и все будет документировано?!
— вы сможете предоставить юридически значимые журналы событий когда к вам придут и скажут что ваша компания ддосит кремлинру?
А что журнал событий обязательно извлекать из SIEM? Он спокойно себе пишется на серверах, бакапится по расписанию.
В случае актуальной угрозы придет алерт на мыло от IDS/Антивирусной защиты/Настроенной на критичных серверах Системы событий Windows/Еще пары забавных штук.
Грамотно закрученные гайки, позволяют минимизировать количество этих сообщений.
— вы сможете сказать кто и когда изменил настройки на сервере\рабочей станции\базе данных\роутере\файерволле?
Логи сохраняются и бакапятся. В реальном времени мониторить, как я говорил, всю инфрастуктуру не нужно. Нужно разделять ее по критичности для бизнеса. Критичные роутеры мониторятся в обязательном порядке.
Про гайки я уже говорил. Например, консоль роутера доступна не всей сети, а специально выделенным машинам.
Если все «да» и вы это сделали с помощью домена — честь и благодать Вам.
Сделано без SIEM, а вот где реально без SIEM не обойтись?
Данная статья не позиционировалась как «купите SIEM, без него нельзя». Можно. Но только когда инфраструктура небольших размеров. С ростом, появляется множество задач по контролю и соблюдению. Политики мало написать, «закрутить гайки» и спокойно пить кофе. Необходимо контролировать их соблюдение. Оправдание «Средний навык рядового пользователя по хакингу систем колышется около 0 уровня» нужно держать в себе и в одном из пунктов модели нарушителя.
Логи бекапятся, ок. Но с какой переодичностью? Достаточной для расследования инцидента? А можно быть уверенной что все необходимые события там будут? Может кто то случайно назначит GPO и там будет лишь пустота. Гарантируется ли юридическая значимость этих забекапленных логов? А если будет многомиллионная транзакция?! Вы сможете привести в суде доказательства, что это действительно те самы логи с того самого сервера, а не фальсифицированные доказательства?!.. Можно их перенаправлять и на Syslog. Но опять же — где кдц. Да и не все источники могут поддерживать tcp syslog — в противном случае, часть событий при потоке выше 5-7к eps syslog udp скорее всего будут потеряны (по результатам тестирования).
SIEM не панацея от 0-day и всех-всех угроз. SIEM — средство автоматизации.
SIEM автоматизирует монотонную работу с журналами событий, выстраивает процессы инцидент-менеджмента, приоритезируя инциденты и фокусируя внимание подразделений ИТ и ИБ на важных для бизнеса. Дополняет процессы управления политиками и комплайнса, управления конфигурациями…
Приходите на рускрипто-2013, у меня как раз будет выступление и пообщаемся в колуарах. Переубеждать я не намеряна, просто расскажу :)
Логи бекапятся, ок. Но с какой переодичностью? Достаточной для расследования инцидента? А можно быть уверенной что все необходимые события там будут? Может кто то случайно назначит GPO и там будет лишь пустота. Гарантируется ли юридическая значимость этих забекапленных логов? А если будет многомиллионная транзакция?! Вы сможете привести в суде доказательства, что это действительно те самы логи с того самого сервера, а не фальсифицированные доказательства?!.. Можно их перенаправлять и на Syslog. Но опять же — где кдц. Да и не все источники могут поддерживать tcp syslog — в противном случае, часть событий при потоке выше 5-7к eps syslog udp скорее всего будут потеряны (по результатам тестирования).
SIEM не панацея от 0-day и всех-всех угроз. SIEM — средство автоматизации.
SIEM автоматизирует монотонную работу с журналами событий, выстраивает процессы инцидент-менеджмента, приоритезируя инциденты и фокусируя внимание подразделений ИТ и ИБ на важных для бизнеса. Дополняет процессы управления политиками и комплайнса, управления конфигурациями…
Приходите на рускрипто-2013, у меня как раз будет выступление и пообщаемся в колуарах. Переубеждать я не намеряна, просто расскажу :)
Переубеждать не надо, вещь эта нужная и интересная несомненно. Хочется понять, насколько нужная. Насколько она стоит своих затрат.
Вот Вашим словам.
Акцент на сборе и хранении. Даже по другому — Юридически значимом сборе и хранении, чтобы опровергнуть многомиллионные транзакции, чтобы следить за кучей серверов, которые все значимы для Бизнеса, собирать с них не убиваемый лог, которым можно потрясти в суде.
Получается, эта тема востребована в основном банковским сектором?
А остальным? Которым не надо трясти бакапами в суде? Остальным по идее, логично было бы надеяться на автоматизацию рутины.
И тут опять всплывает из вашей статьи, что у сегодняшних SIEM «акцент здесь делается на сборе и хранении».
Если он автоматизирует, то каким, образом, ведь Вы пишете.
" в журнале событий каждого источника данных конкретное событие может быть описано различными служебными словами, с разными event_id., выполнение проверки соответствия подобным образом требует слишком большого количества ресурсов, поэтому разработчики SIEM отказываются от этой затеи."
Что в результате приводит опять только лишь, к Юридически значимому логу, без невозможности автоматического анализа.
Вот Вашим словам.
Повторю еще раз: акцент здесь делается на сборе и хранении. Мы не увидим ничего похожего на «анализ», «аудит полученных данных» (не путать с «аудитом входа в систему», это обычные данные из журналов).
…
Если вы ожидаете, что результатом контроля соответствия стандарту с использованием SIEM станет сообщение вида «Установлена минимальная длина пароля» с указанием соответствующего или не соответствующего требования, — вы, к сожалению, ошибаетесь. Отсюда можно сделать вывод, что SIEM-системы не предназначены для оценки соответствия, а нужны как техническое средство для соблюдения отдельных требований стандартов по сбору и хранению событий и имеют лишь функциональность track@report.
Акцент на сборе и хранении. Даже по другому — Юридически значимом сборе и хранении, чтобы опровергнуть многомиллионные транзакции, чтобы следить за кучей серверов, которые все значимы для Бизнеса, собирать с них не убиваемый лог, которым можно потрясти в суде.
Получается, эта тема востребована в основном банковским сектором?
А остальным? Которым не надо трясти бакапами в суде? Остальным по идее, логично было бы надеяться на автоматизацию рутины.
SIEM автоматизирует монотонную работу с журналами событий, выстраивает процессы инцидент-менеджмента, приоритезируя инциденты и фокусируя внимание подразделений ИТ и ИБ на важных для бизнеса.
И тут опять всплывает из вашей статьи, что у сегодняшних SIEM «акцент здесь делается на сборе и хранении».
Если он автоматизирует, то каким, образом, ведь Вы пишете.
" в журнале событий каждого источника данных конкретное событие может быть описано различными служебными словами, с разными event_id., выполнение проверки соответствия подобным образом требует слишком большого количества ресурсов, поэтому разработчики SIEM отказываются от этой затеи."
Что в результате приводит опять только лишь, к Юридически значимому логу, без невозможности автоматического анализа.
Не только банковский сектор. Почти в каждой организации есть банк-клиенты. Представьте что с компьютера бухгалтера переводят максимальную сумму со счета в оффшор. И не важно кто это сделал — троян, сам главный бухгалтер или новая сотрудница с нулевыми знаниями в хакинге.
Представьте, что кто то заимел халявную ноду и поднял VPS. Или сливает по 10-20 литров бензина за смену когда температура в хранилище нагревается до определенного значения. Или когда запускаются процессы на компьютере генерального директора в его отсутствие и отсутствии VPN к его компьютеру.
Когда события собраны в единое хранилище со всех источников (либо таких хранилищ несколько) по ним можно делать корреляцию и определять взаимосвязи, отслеживать тенденции. Открываем дашбоард, и видим всплески трафика на порт, видим кучу неуспешных попыток входа, а затем успешную. Без SIEM эти факты еще предстоит выяснить, после того как мы узнаем об утечке или удалении, к примеру, всей корпоративной информации на файловом хранилище. Или нанимать кучу людей которые будут мониторить логи. Как часто можно смотреть те же журналы событий на VPN? а если Катя, которая все время коннектилась с акадо-москва вдруг залезла на vpn с тайваня? SIEM это увидит, сгенерирует инцидент. причем это должно быть не просто письмо в электронную почту (ибо через неделю никто не будет читать их, или сотрудник заболеет, или сработает человеческий фактор и он попросту пропустит событие при просмотре, потому что клубился всю ночь.
Логи DLP и антивирусного ПО тоже надо смотреть. И конфигурации с логов читать.В противном случае — насколько будет уверено руководство компании что месяц назад админ-ИБ-смотрящий-DLP не взял шоколадку и пропустил за это событие ака «Ваня отослал на какой-то ящик список ваших сотрудников». Антивирусное ПО — да, можно в ПО смотреть ситуацию. Но очень сложно организовать работу, при которой во всей инфраструктуре установлено ПО, обновлено до актуальных баз и с правильными настройками согласно ваших политик и инструкций.
Для ИТ будет лучше поскорее узнать о том что отказал диск в рейде или сервис застопорился. Не по звонку от рассерженных пользователей, которые потеряли часть данных. Да, можно и скриптами. Их не один десяток придется написать. И не одну сотню. Уверены что ИТ специалист среагирует на этот алерт? Или все же лучше зарегистрировать инцидент с опеределенным приоритетом, фиксированными сроками решения и эскалацией в случае его просрочки?
Это все ИТ-Ибшные части. Сейчас все SIEM стремятся приоритезировать инциденты по результатам корреляций и с учетом рисков, исходя из ценности актива, его участия в бизнес-процессах и т.д. В итоге, вы сможете увидеть на какие бизнес-процессы влияют те или иные события.И что будет если остановить сервис\удалить пользователя\не закрыть уязвимость.
Источников много. Угроз и векторов атак еще больше. Нельзя полагаться на «поставил и забыл».
Представьте, что кто то заимел халявную ноду и поднял VPS. Или сливает по 10-20 литров бензина за смену когда температура в хранилище нагревается до определенного значения. Или когда запускаются процессы на компьютере генерального директора в его отсутствие и отсутствии VPN к его компьютеру.
Когда события собраны в единое хранилище со всех источников (либо таких хранилищ несколько) по ним можно делать корреляцию и определять взаимосвязи, отслеживать тенденции. Открываем дашбоард, и видим всплески трафика на порт, видим кучу неуспешных попыток входа, а затем успешную. Без SIEM эти факты еще предстоит выяснить, после того как мы узнаем об утечке или удалении, к примеру, всей корпоративной информации на файловом хранилище. Или нанимать кучу людей которые будут мониторить логи. Как часто можно смотреть те же журналы событий на VPN? а если Катя, которая все время коннектилась с акадо-москва вдруг залезла на vpn с тайваня? SIEM это увидит, сгенерирует инцидент. причем это должно быть не просто письмо в электронную почту (ибо через неделю никто не будет читать их, или сотрудник заболеет, или сработает человеческий фактор и он попросту пропустит событие при просмотре, потому что клубился всю ночь.
Логи DLP и антивирусного ПО тоже надо смотреть. И конфигурации с логов читать.В противном случае — насколько будет уверено руководство компании что месяц назад админ-ИБ-смотрящий-DLP не взял шоколадку и пропустил за это событие ака «Ваня отослал на какой-то ящик список ваших сотрудников». Антивирусное ПО — да, можно в ПО смотреть ситуацию. Но очень сложно организовать работу, при которой во всей инфраструктуре установлено ПО, обновлено до актуальных баз и с правильными настройками согласно ваших политик и инструкций.
Для ИТ будет лучше поскорее узнать о том что отказал диск в рейде или сервис застопорился. Не по звонку от рассерженных пользователей, которые потеряли часть данных. Да, можно и скриптами. Их не один десяток придется написать. И не одну сотню. Уверены что ИТ специалист среагирует на этот алерт? Или все же лучше зарегистрировать инцидент с опеределенным приоритетом, фиксированными сроками решения и эскалацией в случае его просрочки?
Это все ИТ-Ибшные части. Сейчас все SIEM стремятся приоритезировать инциденты по результатам корреляций и с учетом рисков, исходя из ценности актива, его участия в бизнес-процессах и т.д. В итоге, вы сможете увидеть на какие бизнес-процессы влияют те или иные события.И что будет если остановить сервис\удалить пользователя\не закрыть уязвимость.
Источников много. Угроз и векторов атак еще больше. Нельзя полагаться на «поставил и забыл».
Или когда запускаются процессы на компьютере генерального директора в его отсутствие и отсутствии VPN к его компьютеру.
Когда события собраны в единое хранилище со всех источников (либо таких хранилищ несколько) по ним можно делать корреляцию и определять взаимосвязи, отслеживать тенденции. Открываем дашбоард, и видим всплески трафика на порт, видим кучу неуспешных попыток входа, а затем успешную.
Алгоритм корреляции пишет оператор SIEM? Или SIEM это искусственный интеллект (свершилось!), который сам решает что важно, а что нет?
SIEM не равно продукт из коробки. Есть предзаданные правила корреляции. Правила корреляции пишутся дополнительно при интеграции. Правила дополняются при пентестах, аудитах и т.п. (PDCA).
Простому оператору не стоит доверять писать правила корреляции. Вообще, чем больше правил корреляции — тем больше нагрузка на сервер (см. мои статьи в цикле по SIEM. Счетчики и триггеры висят в памяти)
Маской описывается кейс запуска процессов или сетевых коннектах при отсутствии сотрудника (интеграция агента и скуда — уже в практике давно применяется, но реализация возможна не на всех сиемах).
Статистика дашбордов репрезентативно показывает всплески от baseline.
Простому оператору не стоит доверять писать правила корреляции. Вообще, чем больше правил корреляции — тем больше нагрузка на сервер (см. мои статьи в цикле по SIEM. Счетчики и триггеры висят в памяти)
Маской описывается кейс запуска процессов или сетевых коннектах при отсутствии сотрудника (интеграция агента и скуда — уже в практике давно применяется, но реализация возможна не на всех сиемах).
Статистика дашбордов репрезентативно показывает всплески от baseline.
Да вот меня смутило про отлов перевода в офшор… А если мелкими суммами накидать? А если оформлять на подставных людей?
www.securitylab.ru/news/438210.php
Сразу мысль, про ИИ который бдит, его еще к камерам подключить, он будет по выражению лица определять плохишей.
Есть еще вопрос.
Вот представим сеть из 1000 машин, куча роутеров, скуд, идем по вашему принципу собираем в SIEM все возможные события, гребем лопатой по максимуму, а то мало ли что. Угроз и векторов полно. Отслеживаем все, вплоть до смарта хардов, харды ведь тоже надо менять вовремя.
Сможет ли отдел ИБ разгребать все, что ему начнет валить SIEM, чтобы не по факту карать, а заранее предотвращать.
Вот сработка SIEM, по скуду человека нет, а машина активна. Отряд ИБ несется на крыльях ночи, в удаленный офис, а там баба Маня случайно шваброй задела кнопку Повер.
Вот с нового ip попер какой то непонятный VPN трафик, карательный отряд подрывается, но оказывается это dhcp сменил адрес старой машины, на новый.
Вот какой то непонятный траф стал генериться с компа генерального директора, все садятся на измену, в итоге выясняется, что это гендир просто решил зарубиться в контру по инету.
Сколько будет вот такого ложняка, при том количестве информации, что будет получать SIEM с 1000 хостов?
Может имеет смысл к отряду операторов, пишуших корреляции, внедрить отдельный отряд реагирования на отклонения от baseline?
www.securitylab.ru/news/438210.php
Сразу мысль, про ИИ который бдит, его еще к камерам подключить, он будет по выражению лица определять плохишей.
Есть еще вопрос.
Вот представим сеть из 1000 машин, куча роутеров, скуд, идем по вашему принципу собираем в SIEM все возможные события, гребем лопатой по максимуму, а то мало ли что. Угроз и векторов полно. Отслеживаем все, вплоть до смарта хардов, харды ведь тоже надо менять вовремя.
Сможет ли отдел ИБ разгребать все, что ему начнет валить SIEM, чтобы не по факту карать, а заранее предотвращать.
Без SIEM эти факты еще предстоит выяснить, после того как мы узнаем об утечке или удалении, к примеру, всей корпоративной информации на файловом хранилище.
Вот сработка SIEM, по скуду человека нет, а машина активна. Отряд ИБ несется на крыльях ночи, в удаленный офис, а там баба Маня случайно шваброй задела кнопку Повер.
Вот с нового ip попер какой то непонятный VPN трафик, карательный отряд подрывается, но оказывается это dhcp сменил адрес старой машины, на новый.
Вот какой то непонятный траф стал генериться с компа генерального директора, все садятся на измену, в итоге выясняется, что это гендир просто решил зарубиться в контру по инету.
Сколько будет вот такого ложняка, при том количестве информации, что будет получать SIEM с 1000 хостов?
Может имеет смысл к отряду операторов, пишуших корреляции, внедрить отдельный отряд реагирования на отклонения от baseline?
чтобы не по факту карать, а заранее предотвращать.
В большинстве случаев-таки именно по факту карать. С доказательной базой, которой не только в суде трясти, но и для внутренних документов. Ну или чтобы пользователю пальчиком погрозить «Вася, не надо так делать!» — но если инфидент есть в SIEM, то он уже произошел.
Другой вопрос, что, может быть инцидент не имел продолжения ввиду того, что сработала какая-то другая система ИБ
Sign up to leave a comment.
Соответствие стандартам и политикам в сканерах уязвимостей и SIEM