Size: a a a

SOС Технологии

2020 May 14

i

ilya in SOС Технологии
yugoslavskiy
поцоны подскажите пожалуйста через кого кто закупает tenable?

пока нашлись вот эти ребята:

-группа компаний "Вета": http://www.weta.ru/about-advantage.php
- системный софт:  https://www.syssoft.ru/

мне бы пообщаться по поводу статуса реселлера tenable.io
Приветствую! Тайгер Оптикс (мы) — дистрибьютор Tenable в России.

Буду рад помочь по вопросам
io@tiger-optics.ru
источник

DR

Dmitriy Roschenko in SOС Технологии
Подскажите кто нибудь пробовал FortiSOAR?
источник

P

Pavlo in SOС Технологии
огромного опыта не было....ранее это был продукт CyberSponse (индусы), а в конце прошлого года фортик их выкупил...интеграций (коннекторов) с другими системами/устройствами/платформами достаточное количество...что-то конкретное интересует?
источник
2020 May 15

m

mad3e7cat in SOС Технологии
Привет, хотелось бы услышать разные мнения. Есть два стула:
1. Определить для себя скоуп данных, по которым хотелось бы искать в siem и дорабатывать по своему усмотрению этот список, добавляя новые источники информации. Тут я вижу проблему в том, что в случае возникновения новых типов атак или изменения профиля старых у нас будут слепые пятна.
2. Собираем все, что можем и потом уже занимаемся исключением по тому, что сочтем ненужным. Мне интуитивно кажется, что в таком случае мы имеем меньше слепых пятен, так как даже предполагая, что какой-то источник информации нам нужен и не убирая его, даже "на всякий случай", повышаем шансы заметить определенную атаку.
источник

NA

Nikolai Arefiev in SOС Технологии
Этот вопрос тут поднимается уже 3 раз :)
источник

NA

Nikolai Arefiev in SOС Технологии
@yugoslavskiy Не хочешь на этот счет сделать заметку или статью?
источник

NA

Nikolai Arefiev in SOС Технологии
mad3e7cat
Привет, хотелось бы услышать разные мнения. Есть два стула:
1. Определить для себя скоуп данных, по которым хотелось бы искать в siem и дорабатывать по своему усмотрению этот список, добавляя новые источники информации. Тут я вижу проблему в том, что в случае возникновения новых типов атак или изменения профиля старых у нас будут слепые пятна.
2. Собираем все, что можем и потом уже занимаемся исключением по тому, что сочтем ненужным. Мне интуитивно кажется, что в таком случае мы имеем меньше слепых пятен, так как даже предполагая, что какой-то источник информации нам нужен и не убирая его, даже "на всякий случай", повышаем шансы заметить определенную атаку.
Загляните к ребятам в проект https://github.com/atc-project/atomic-threat-coverage
источник

Z

Zer🦠way in SOС Технологии
mad3e7cat
Привет, хотелось бы услышать разные мнения. Есть два стула:
1. Определить для себя скоуп данных, по которым хотелось бы искать в siem и дорабатывать по своему усмотрению этот список, добавляя новые источники информации. Тут я вижу проблему в том, что в случае возникновения новых типов атак или изменения профиля старых у нас будут слепые пятна.
2. Собираем все, что можем и потом уже занимаемся исключением по тому, что сочтем ненужным. Мне интуитивно кажется, что в таком случае мы имеем меньше слепых пятен, так как даже предполагая, что какой-то источник информации нам нужен и не убирая его, даже "на всякий случай", повышаем шансы заметить определенную атаку.
Наверное 2 и тогда вы сможете видеть аномалии и возможно новые атаки
источник

A

Anton in SOС Технологии
mad3e7cat
Привет, хотелось бы услышать разные мнения. Есть два стула:
1. Определить для себя скоуп данных, по которым хотелось бы искать в siem и дорабатывать по своему усмотрению этот список, добавляя новые источники информации. Тут я вижу проблему в том, что в случае возникновения новых типов атак или изменения профиля старых у нас будут слепые пятна.
2. Собираем все, что можем и потом уже занимаемся исключением по тому, что сочтем ненужным. Мне интуитивно кажется, что в таком случае мы имеем меньше слепых пятен, так как даже предполагая, что какой-то источник информации нам нужен и не убирая его, даже "на всякий случай", повышаем шансы заметить определенную атаку.
второй способ ущербный по-дефолту. имхо
источник

A

Anton in SOС Технологии
case-by-case
источник

NA

Nikolai Arefiev in SOС Технологии
Anton
второй способ ущербный по-дефолту. имхо
расскажите это при Threat Hunting-е
источник

A

Anton in SOС Технологии
Nikolai Arefiev
расскажите это при Threat Hunting-е
Вы собираете 30% всех возможных событий и инфраструктуре и 75% всех событий в инфраструктуре, при этом в обоих случаях вы обрабатываете 5% событий. В какой ситуации защищённость выше?
источник

NA

Nikolai Arefiev in SOС Технологии
В последний раз, когда тут спорили по данному вопросу, однозначного ответа не нашлось )
источник

y

yugoslavskiy in SOС Технологии
Nikolai Arefiev
@yugoslavskiy Не хочешь на этот счет сделать заметку или статью?
да вот мы вплотную полошли к тому чтобы составить классификацию необходимых данных с привязкой к Threat Detection и Incident Response. все время к этому шли, и вот уже почти пришли
источник

y

yugoslavskiy in SOС Технологии
есть разные проекты которые вроде как классифицируют эти вещи, но за этой оценкой ничего не стоит
источник

y

yugoslavskiy in SOС Технологии
а мы хотим чтобы чекто было, как-то так (диалог безопасника и админа):

"а нафига тебе process execution лог?"
"а вот":

- список Sigma правил
- список Response Actions
источник

y

yugoslavskiy in SOС Технологии
Nikolai Arefiev
В последний раз, когда тут спорили по данному вопросу, однозначного ответа не нашлось )
да нашелся он на самом деле, и спорить особо нечего
источник

Z

Zer🦠way in SOС Технологии
Anton
Вы собираете 30% всех возможных событий и инфраструктуре и 75% всех событий в инфраструктуре, при этом в обоих случаях вы обрабатываете 5% событий. В какой ситуации защищённость выше?
В той когда за клавиатурой сидит не овощ
источник

y

yugoslavskiy in SOС Технологии
те кто об этом спорят просто никогда на самом деле не пробовали собрать все и засунуть в процессиннг
источник

y

yugoslavskiy in SOС Технологии
один раз попробуешь, больше спорить не будешь
источник