Size: a a a

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

2020 October 01

KV

Kirill Valtts in SOС Технологии
1 2
Собственно подход понятен, но интересно реализация. Необязательно аптайм, можно и любой другой эффекти, например нагрузка на сеть, повышенное энергопотребление и другое
Если есть ИТ-инцидент, значит есть влияние. Если нет, значит ИТ пофиг и безопасности можно не париться
источник

RI

Ruslan Ivanov in SOС Технологии
Kirill Valtts
Если есть ИТ-инцидент, значит есть влияние. Если нет, значит ИТ пофиг и безопасности можно не париться
Чувствуется рука мастера 😂👏
источник

RI

Ruslan Ivanov in SOС Технологии
На самом деле, это далеко не всегда очевидный момент, и влияние часто не может быть обнаружено in vivo, а только постфактум
источник

RI

Ruslan Ivanov in SOС Технологии
На самом деле, к тому что написал Кирилл, я бы ещё добавил категоризацию активов для определения этой самой бизнес-критичности, для того чтобы правильно управлять уровнями инцидентов
источник

KV

Kirill Valtts in SOС Технологии
Ruslan Ivanov
На самом деле, это далеко не всегда очевидный момент, и влияние часто не может быть обнаружено in vivo, а только постфактум
Конечно, поэтому нужно завязывать категоризацию инцидентов КБ в том числе и ИТ инциденты. Ну, и пост-анализ никто не отменял.
По ИТ-инцидентам тоже потом разбор полетов
источник

KV

Kirill Valtts in SOС Технологии
Ruslan Ivanov
На самом деле, к тому что написал Кирилл, я бы ещё добавил категоризацию активов для определения этой самой бизнес-критичности, для того чтобы правильно управлять уровнями инцидентов
Да!
источник

RI

Ruslan Ivanov in SOС Технологии
Т.е. не только кинетическая реакция на инцидент после пинка от руководства, но и расчёт потенциальной (ну или накопительной) энергии мелких инцидентов
источник

KV

Kirill Valtts in SOС Технологии
Ruslan Ivanov
Т.е. не только кинетическая реакция на инцидент после пинка от руководства, но и расчёт потенциальной (ну или накопительной) энергии мелких инцидентов
Тут нужно разделять. Если у многих мелких инцидентов причина одна, то делаем корневой, повышаем его критичность (согласно заранее разработанных критериев), и привязываем мелкие к корневому.
А вот если причины разные, то объединять не стоит.

Если есть простои бизнеса, то конечно же потом все агрегируется и считается за какой-то период. Но тут интересно совокупное влияние на бизнес
источник

12

1 2 in SOС Технологии
Вот собственно с точки зрения техники это было бы интересно. Про опыт может)
источник

RI

Ruslan Ivanov in SOС Технологии
Kirill Valtts
Тут нужно разделять. Если у многих мелких инцидентов причина одна, то делаем корневой, повышаем его критичность (согласно заранее разработанных критериев), и привязываем мелкие к корневому.
А вот если причины разные, то объединять не стоит.

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

V

V in SOС Технологии
всем привет, посоветуйте оптимальную методологию проведения спринтов по разбору инцидентов (смотрю в сторону scrum, но не совсем)
источник

y

yugoslavskiy in SOС Технологии
V
всем привет, посоветуйте оптимальную методологию проведения спринтов по разбору инцидентов (смотрю в сторону scrum, но не совсем)
мне тоже расскажите пожалуйста какие там спринты для IR есть
источник

NA

Nikolai Arefiev in SOС Технологии
IR Scrum-mater нннаада?
источник

IB

Igor Belyakov in SOС Технологии
yugoslavskiy
мне тоже расскажите пожалуйста какие там спринты для IR есть
Может только если приравнять инциденты к багам ... ну и дальше по флоу разработки )))
Хотя конечно странный подход
источник

IG

Ilya Glotov in SOС Технологии
если под разбором понимать этапы lessons learned -> preparation, то скрам вполне норм и кое-где так и работает)
источник

y

yugoslavskiy in SOС Технологии
Ilya Glotov
если под разбором понимать этапы lessons learned -> preparation, то скрам вполне норм и кое-где так и работает)
хм, действительно.
источник
2020 October 02

NM

Nastya Mansurova in SOС Технологии
Всем привет!

Positive Technologies открывает стажировку в ряд команд Blue Team!
Задачи есть разные: начиная от написания YARA правил и анализа вредоносного ПО до расследования инцидентов, а также автоматизация различных задач мониторинга ИБ.
Занятость от 20 до 40 часов в неделю.
Есть возможность пройти стажировку удаленно.

Требования:
* Базовое понимание архитектуры ОС Windows
* Представление, как работает вредоносное ПО
* Знакомство с YARA/Sigma правилами


Резюме с пометкой "Стажировка в Blue Team" присылайте на amansurova@ptsecurity.com

Хорошего дня)
источник

$

$t3v3;0) in SOС Технологии
Вот во мне сейчас граммар наци прям разбушевался :)
источник

e

e6e6e in SOС Технологии
Nastya Mansurova
Всем привет!

Positive Technologies открывает стажировку в ряд команд Blue Team!
Задачи есть разные: начиная от написания YARA правил и анализа вредоносного ПО до расследования инцидентов, а также автоматизация различных задач мониторинга ИБ.
Занятость от 20 до 40 часов в неделю.
Есть возможность пройти стажировку удаленно.

Требования:
* Базовое понимание архитектуры ОС Windows
* Представление, как работает вредоносное ПО
* Знакомство с YARA/Sigma правилами


Резюме с пометкой "Стажировка в Blue Team" присылайте на amansurova@ptsecurity.com

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

Z

Zer🦠way in SOС Технологии
e6e6e
Думаю, что по каждому направлению лучше указать минимальные необходимые требования к кандидатам на стажировку, т к для ребят, которым интересна такая стажировка, это может быть неочевидно.
и не очевидно что для пенсионеров оно не подходит)))
источник