Gonebny-Timesheets-SOCF2023.pdf
1.7 MB
Работа SOC напрямую зависит от работы аналитиков. Усталость, утомленность аналитиков негативно влияет на результат, ребята ошибаются.
Организация сменной работы - самый эффективный инструмент снижения влияния физической усталости аналитиков на работу всего подразделения, поэтому переоценить важность этого вопроса невозможно.
За время работы нашего SOC с 2016 мы прошли долгий путь(часть его я прошел еще в прошлой жизни, поэтому в 2016 мы стартовали не с самых ужасных графиков ), а в 2023 году, на SOC Forum, мой коллега и друг, Альберт Гонебный, сделал замечательный доклад о том, как нам удалось выработать сменный график, как нам кажется, наиболее комфортный для команды - "От ночных недосыпов к work-life balance, или как организовать комфортный график дежурств для аналитиков"
Слайды доступны во вложении.
Ссылка на видео.
#MDR #управление
Организация сменной работы - самый эффективный инструмент снижения влияния физической усталости аналитиков на работу всего подразделения, поэтому переоценить важность этого вопроса невозможно.
За время работы нашего SOC с 2016 мы прошли долгий путь
Слайды доступны во вложении.
Ссылка на видео.
#MDR #управление
👍11❤6🔥1
На днях мне попался документ про фингерпринтинг (наверно, можно по-русски сказать "профилирование") браузеров. Документ не очень относится и к моей профессиональной деятелности, и к увлечениям, тем не менее, мне он показался интересным, и я его дочитал до конца. В этой заметке поделюсь посетившими меня мыслями.
0. Сводную табличку со всеми, упомянутыми в статье, методами профилирования и их свойствами, я вывел в картинке к заметке.
1. Вспомнился классический документ Федора про фингерпринтинг TCP/IP реализаций в разных ОС. И вот теперь мы поднялись на уровень приложения.
2. Построение системы безопасной аутентификации возможно только в ущерб приватности. Это еще один принципиальный постулат, аналогичный тому, что невозможно построить ML-модель, которую не сможет обмануть человек. Принцип в полной мере работает и в реальной жизни: предъявляя паспорт на входе вахтеру, который записывает его данные в свой журнальчик входов\выходов, я повергаю риску компрометации свои паспортые данные. Причем, чем более безопасный механизм аутентификации мне надо построить, тем больше своей приватности мне надо передать: чем более точно проверяющему надо определить меня, тем большую частью себя мне надо поделиться с проверяющим. Приложенная картинка с разбиранием приватности ради безопасности - прекрасная иллюстрация этого принципа. В этой связи, любой механизм профилирования всегда будет иметь "privacy impact", и поэтому доносимый статьей "мессидж" выглядит как очевидная очевидность. Тем не менее, статья содержит неплохой обзор того, что в принципе может собираться при профилировании.
3. Все это профилирование - лишнее подтверждение, что для важных рабочих задач следует пользоваться одним браузером, а для всякой ерунды - другим, может, и в incognito mode, в надежде на то, что в этом режиме "всякая ерунда" получит меньшую часть меня в свое распоряжение.
0. Сводную табличку со всеми, упомянутыми в статье, методами профилирования и их свойствами, я вывел в картинке к заметке.
1. Вспомнился классический документ Федора про фингерпринтинг TCP/IP реализаций в разных ОС. И вот теперь мы поднялись на уровень приложения.
2. Построение системы безопасной аутентификации возможно только в ущерб приватности. Это еще один принципиальный постулат, аналогичный тому, что невозможно построить ML-модель, которую не сможет обмануть человек. Принцип в полной мере работает и в реальной жизни: предъявляя паспорт на входе вахтеру, который записывает его данные в свой журнальчик входов\выходов, я повергаю риску компрометации свои паспортые данные. Причем, чем более безопасный механизм аутентификации мне надо построить, тем больше своей приватности мне надо передать: чем более точно проверяющему надо определить меня, тем большую частью себя мне надо поделиться с проверяющим. Приложенная картинка с разбиранием приватности ради безопасности - прекрасная иллюстрация этого принципа. В этой связи, любой механизм профилирования всегда будет иметь "privacy impact", и поэтому доносимый статьей "мессидж" выглядит как очевидная очевидность. Тем не менее, статья содержит неплохой обзор того, что в принципе может собираться при профилировании.
3. Все это профилирование - лишнее подтверждение, что для важных рабочих задач следует пользоваться одним браузером, а для всякой ерунды - другим, может, и в incognito mode, в надежде на то, что в этом режиме "всякая ерунда" получит меньшую часть меня в свое распоряжение.
👍8🔥1🖕1
Вчера с супругой попробовали новый формат культурного досуга. Собираемся узким кругом друзей и знакомых в хорошем кафе и приглашаем интересных спикеров, а после небольшой лекции - обсуждение услышанного.
Вчера нашим гостем была Дарья, дипломированный искусствовед и философ, а тема - современное искусство. Замечу, что к выбору темы я приложился сам, поскольку этот предмет нередко вызывает у меня негативные эмоции, что я пытаюсь объяснить тем, что просто не разбираюсь в вопросе.
В новой статье я делюсь идеями, обсуждаемыми после лекции, которые мне показались интересными.
#искусство
Вчера нашим гостем была Дарья, дипломированный искусствовед и философ, а тема - современное искусство. Замечу, что к выбору темы я приложился сам, поскольку этот предмет нередко вызывает у меня негативные эмоции, что я пытаюсь объяснить тем, что просто не разбираюсь в вопросе.
В новой статье я делюсь идеями, обсуждаемыми после лекции, которые мне показались интересными.
#искусство
Дзен | Статьи
Современное искусство
Статья автора «REPLY-TO-ALL Information Security Blog» в Дзене ✍: Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать.
🔥13❤1🤮1🤡1🍌1🖕1
Мой друг и коллега, Саша Родченко, из нашей команды Detection Engineering MDR, в этом году на BH MEA будет рассказывать об ошибках атакующих, за которые их ловит SOC.
Но это не все!
Мой, не менее друг и коллега Амджед, из нашей команды Compromise Assessment, расскажет об анализе артефактов Google Drive, о чем можно почитать анонс в канале Управления Сервисов.
#MDR #kaspersky
Но это не все!
Мой, не менее друг и коллега Амджед, из нашей команды Compromise Assessment, расскажет об анализе артефактов Google Drive, о чем можно почитать анонс в канале Управления Сервисов.
#MDR #kaspersky
Blackhatmea
Black Hat MEA Cybersecurity Event | 2-4 December 2025
Black Hat is one of the world’s largest infosec events, bringing together global CISOs, elite ethical hackers & 45,000+ visitors in Riyadh, Saudi Arabia
🔥11👍3🙏1
Всем привет! Как обещал, сегодня я в Минске у друзей из А1 Беларусь, на A1 Tech Day.
Есть возможность/желание, пишите, пересечемся.
Есть возможность/желание, пишите, пересечемся.
👍17🔥6❤4
2024-11-A1_Minsk_Soldatov-v2.pdf
3 MB
Выкладываю презентацию с мероприятия.
Вынужден сознаться, что мультик из слайдов 7-10 я уже рассказывал на митапе пентестеров, но иллюстрированный здесь вопрос, на мой взгляд, очень важен, а так как нет видео записи, позволю себе по этой теме написать еще и заметку, так как подобного объяснения, за почти уже год, как я рассказал эту концепцию, не виделдаже у Гартнера .
Если по презентации что-то еще не ясно\спорно, пишите вопросы в комментариях, непонятные моменты распишу в новых заметках.
#vCISO
Вынужден сознаться, что мультик из слайдов 7-10 я уже рассказывал на митапе пентестеров, но иллюстрированный здесь вопрос, на мой взгляд, очень важен, а так как нет видео записи, позволю себе по этой теме написать еще и заметку, так как подобного объяснения, за почти уже год, как я рассказал эту концепцию, не видел
Если по презентации что-то еще не ясно\спорно, пишите вопросы в комментариях, непонятные моменты распишу в новых заметках.
#vCISO
🔥12👍1
Следует поблагодарить Дэна за подробные разъяснения, а мне ничего не остается, кроме как его процитировать.
Проголосовать можно и за наш канал по ссылке
https://t.iss.one/boost/soldatov_in_telegram
Проголосовать можно и за наш канал по ссылке
https://t.iss.one/boost/soldatov_in_telegram
Telegram
Топ кибербезопасности Батранкова
Я не публикую рекламу, при этом у меня спросили - как появляется реклама в моем канале. Рассказываю. )
1. Телеграм сам показывает рекламу в каналах с аудиторией более 1000 подписчиков.
2. Я, как владелец канала, не могу контролировать или отключать рекламу…
1. Телеграм сам показывает рекламу в каналах с аудиторией более 1000 подписчиков.
2. Я, как владелец канала, не могу контролировать или отключать рекламу…
Вчера мне довелось побывать в Государственной Думе. В зале ЛДПР состоялся круглый стол "Практика противодействия кибератакам", аудитория - представители отрасли, как поставщики решений, так и их потребители. Хочется выразить слова благодарности компании Angara security, персонально Сергею Петровичу Шерстобитову и Тимуру Зиннятуллину, и за организацию мероприятия и за возможность принять участие - чем плотнее экспертное сообщество будет работать с законодательной властью, тем эффективнее и результативнее будут наши общие усилия по противодействию кибератакам и кибертерроризму.
Мне выпал вопрос: "Как нам, как представителям индустрии, вести себя в разгар кибервойны, как выстраивать отношения со всеми вовлеченными сторонами, включая государство? Как разделять зоны ответственности, особенно между Заказчиками и Подрядчиками?". Так как записи нет тезисно отвечу на него здесь.
0. Поскольку наше общение происходило в стенах ГД, я выделю кратко инициативы, которые можно было бы рассмотреть с позиции государственного регулирования отрасли.
1. Для того, чтобы быть эффективными и результативными, нам надо быть организованными, аналогично корпоративной бизнес-функции ИБ, тем более, что государственная система управления ИБ (СУИБ) во многом похожа на СУИБ крупной корпорации.
2. Стандартизация. Под типовые элементы инфраструктуры должны быть разработаны профили защиты, и эти профили должны быть обязательны для исполнения в ГИС и КИИ. Пример из жизни - NIST SP 800-53 - исчерпывающий каталог контролей, обязательный для исполнения в американских ГИС.
3. Потребовав исполнение профилей защиты, результат необходимо обязательно проверять.
3.1. На госпредприятиях есть "мероприятия по оценке защищенности" (МОЗ) по сценарию пентест, можно дополнительно ввести оценки соответствия - по каждому обязательному контролю убедиться, что он внедрен и работает с предполагаемым качеством.
3.2. Контроли необходимо обложить метриками и результаты их измерения собирать. По истории измерений метрик можно анализировать тенденции. Отчетность по измерению метрик работы контролей можно поднять на уровень федеральных координационных центров - как мы собираем информацию об инцидентах в НКЦКИ, можно собирать и данные о метриках контролей безопасности.
3.3. Выработанные профили защиты необходимо регулярно проверять, для получения уверенности, что наши наборы контролей отвечают современному ландшафту угроз.
4. Эксплуатация доверительных отношений по данным статистики инцидентов за 2023 и 2024 входит в топ 5 векторов проникновения в сети, поэтому требования по контролям пп.2-3 необходимо распространить на подрядчиков, в целом, это должно стать квалификационным требованием. Это можно сделать, например, лицензированием, а подтверждать соответствие, например, могут лицензированные аудиторы\ пентестеры.
5. Если мы говорим о ПО, то здесь также поможет сертификация. Только сертифицировать надо не конкретные образцы ПО, а процесс разработки - представляется эффективнее сертифицировать конвейер, чем каждое изделие, выходящее с него.
По разделению ответственности - вопрос стандартный. Владельцем ГИС и КИИ следует рассматривать Государство, поэтому видится правильным, что Государство выдвигает требования по обеспечению их безопасности и постоянно контролирует результат. Важный момент здесь - адекватность требований, в противном случае, сами эти требования будут стимулировать их невыполнение. Адекватность может валидироваться экспертным сообществом, ну или возродить институт специализированных НИИ, как в СССР, однако верификация идей НИИ на производстве - обязательна.
А по распределению задач на предприятии я уже давно писал. Если коротко, то чем больше корпоративной специфики тем эффективнее делать самому, а стандартные вещи - в аутсорсинг.
#управление #РФ #vCISO
Мне выпал вопрос: "Как нам, как представителям индустрии, вести себя в разгар кибервойны, как выстраивать отношения со всеми вовлеченными сторонами, включая государство? Как разделять зоны ответственности, особенно между Заказчиками и Подрядчиками?". Так как записи нет тезисно отвечу на него здесь.
0. Поскольку наше общение происходило в стенах ГД, я выделю кратко инициативы, которые можно было бы рассмотреть с позиции государственного регулирования отрасли.
1. Для того, чтобы быть эффективными и результативными, нам надо быть организованными, аналогично корпоративной бизнес-функции ИБ, тем более, что государственная система управления ИБ (СУИБ) во многом похожа на СУИБ крупной корпорации.
2. Стандартизация. Под типовые элементы инфраструктуры должны быть разработаны профили защиты, и эти профили должны быть обязательны для исполнения в ГИС и КИИ. Пример из жизни - NIST SP 800-53 - исчерпывающий каталог контролей, обязательный для исполнения в американских ГИС.
3. Потребовав исполнение профилей защиты, результат необходимо обязательно проверять.
3.1. На госпредприятиях есть "мероприятия по оценке защищенности" (МОЗ) по сценарию пентест, можно дополнительно ввести оценки соответствия - по каждому обязательному контролю убедиться, что он внедрен и работает с предполагаемым качеством.
3.2. Контроли необходимо обложить метриками и результаты их измерения собирать. По истории измерений метрик можно анализировать тенденции. Отчетность по измерению метрик работы контролей можно поднять на уровень федеральных координационных центров - как мы собираем информацию об инцидентах в НКЦКИ, можно собирать и данные о метриках контролей безопасности.
3.3. Выработанные профили защиты необходимо регулярно проверять, для получения уверенности, что наши наборы контролей отвечают современному ландшафту угроз.
4. Эксплуатация доверительных отношений по данным статистики инцидентов за 2023 и 2024 входит в топ 5 векторов проникновения в сети, поэтому требования по контролям пп.2-3 необходимо распространить на подрядчиков, в целом, это должно стать квалификационным требованием. Это можно сделать, например, лицензированием, а подтверждать соответствие, например, могут лицензированные аудиторы\ пентестеры.
5. Если мы говорим о ПО, то здесь также поможет сертификация. Только сертифицировать надо не конкретные образцы ПО, а процесс разработки - представляется эффективнее сертифицировать конвейер, чем каждое изделие, выходящее с него.
По разделению ответственности - вопрос стандартный. Владельцем ГИС и КИИ следует рассматривать Государство, поэтому видится правильным, что Государство выдвигает требования по обеспечению их безопасности и постоянно контролирует результат. Важный момент здесь - адекватность требований, в противном случае, сами эти требования будут стимулировать их невыполнение. Адекватность может валидироваться экспертным сообществом, ну или возродить институт специализированных НИИ, как в СССР, однако верификация идей НИИ на производстве - обязательна.
А по распределению задач на предприятии я уже давно писал. Если коротко, то чем больше корпоративной специфики тем эффективнее делать самому, а стандартные вещи - в аутсорсинг.
#управление #РФ #vCISO
🔥20👍6👏1🙏1
2024-11-Soldatov-Bizone-SOC-v0.pdf
2.6 MB
Публикую слайды с сегодняшней встречи на площадке BI.zone по теме облегчения работы аналитиков SOC.
На слайдах есть ссылки на прошлые публикации\доклады по теме, во время презентации я старался не повторяться.
Начал с процессов, о которых не так часто рассказывают, хотя влияние процессов на эффективность SOC невозможно переоценить, а по части автоматизации остановился на тех решениях, которые снимают бóльшую часть проблем аналитиков. Старался не касаться темы машобуча, но не получилось, видимо, это уже давно комодити.
Организаторы сказали, что подобная встреча повторится еще раз, но уже с другими выступающими. Сегодня были Bi.zone, ЛК, Ангара и Яндекс. Все презентации организаторы обещали опубликовать.
#MDR
На слайдах есть ссылки на прошлые публикации\доклады по теме, во время презентации я старался не повторяться.
Начал с процессов, о которых не так часто рассказывают, хотя влияние процессов на эффективность SOC невозможно переоценить, а по части автоматизации остановился на тех решениях, которые снимают бóльшую часть проблем аналитиков. Старался не касаться темы машобуча, но не получилось, видимо, это уже давно комодити.
Организаторы сказали, что подобная встреча повторится еще раз, но уже с другими выступающими. Сегодня были Bi.zone, ЛК, Ангара и Яндекс. Все презентации организаторы обещали опубликовать.
#MDR
🔥18
Наверно, это очевидно, что на КПЭ команд разработки положительно влияют выполненные ими CR/BRQ (Change Request, Business ReQurements) и негативно влияют дефекты (ошибки, bugs). Однако, даже от таких гигантов как Microsoft мы до сих пор нередко слышим, что какой-то баг - это вовсе не баг, а фича, что лишний раз подтверждает, что даже в зрелых конторах дефекты не всегда распознают как дефекты, или .... у них те же КПЭ - плюсы в карму за фичи, и минусы за баги.
Но в этом случае следует опасаться, что КПЭ сработает ровно наоборот: можно писать некачественный код с кучей багов, выявленные и зарегистрированные в трекере баги объявлять фичами, переводить их в CR-ы и получать плюсы в карму за их реализацию.
#dev #пятница
Но в этом случае следует опасаться, что КПЭ сработает ровно наоборот: можно писать некачественный код с кучей багов, выявленные и зарегистрированные в трекере баги объявлять фичами, переводить их в CR-ы и получать плюсы в карму за их реализацию.
#dev #пятница
😁4🔥2💯1
Вчера, ура!, добрался до Передвижников в Третьяковке.
Эти художники и эти картины также откликаются в моей памяти, как Щелкунчик или Мастер и Маргарита. Всегда интересно вспомнить свои мысли тридцатилетней давности...
Ну, а о чем я размышлял, прогуливаясь по выставке вчера, описал в небольшой статье "Передвижники" на Дзен.
Сразу замечу, что я не разбираюсь в искусстве и, вполне возможно, некоторые моменты вижу или понимаю неправильно, я - любитель, поэтому несогласных и инициативных приглашаю в комментарии, обсудим, буду стараться не упустить свою возможность узнать и понять что-то новое.
#искусство
Эти художники и эти картины также откликаются в моей памяти, как Щелкунчик или Мастер и Маргарита. Всегда интересно вспомнить свои мысли тридцатилетней давности...
Ну, а о чем я размышлял, прогуливаясь по выставке вчера, описал в небольшой статье "Передвижники" на Дзен.
Сразу замечу, что я не разбираюсь в искусстве и, вполне возможно, некоторые моменты вижу или понимаю неправильно, я - любитель, поэтому несогласных и инициативных приглашаю в комментарии, обсудим, буду стараться не упустить свою возможность узнать и понять что-то новое.
#искусство
👍20🔥7👏2
На круглом столе присутствовал представитель АНО "Координационный центр национального домена сети Интернет", а освещаемый им вопрос - "Какие тенденции можно считать сегодня актуальными с точки зрения изменений в системах общих доменных имен как верхнего уровня, так и национального? С какими задачами сегодня сталкиваются специалисты в этой и смежных областях?"
Однако, в этой заметке хочется затронуть вопросы от представителей реального бизнеса, а их было примерно два:
1. Киберсквоттинг. Т.е. защита бренда компаний. Что делают регистраторы для того, чтобы ловкие ребята не захватывали доменные имена, релевантные крупным компаниям и не перепродавали их затем за бешеные деньги?
2. Фишинговые домены. Т.е. защита от появления доменов вредоносной направленности (по схеме тайпосквоттинга и т.п.), реализующие, например, воровство аутентификационных данных. Что делают регистраторы для того, чтобы подобные фишинговые сайты (пример, из последнего) не возникали в таком количестве, ввиду недопустимой простоты регистрации домена.
Короткий ответ на оба вопроса: регистраторы для решения проблем пп. 1-2 не дели ничего в 2001 году (мое первое место работы), ничего не делают сейчас, и не планируют. И для того, чтобы они что-то начали с этим делать, их надо обязать на уровне регулятора.
Дело здесь в том, что Регистратор - это коммерческая контора и, по большому счету, ему все равно с кого он получит свои $20 за домен, а чем больше регистрируется доменов - тем выше у него объем продаж. Поэтому, перекрывая какую-то долю потока регистрации доменов или как-то затрудняя процесс, что приведет к снижению регистраций доменов, Регистратор будет просто сокращать свои продажи, что, очевидно, экономически невыгодно. Поэтому здесь единственный инструмент - compliance, который надо потребовать со стороны госрегулятора.
Мероприятия по решению обеих обозначенных проблем (и захват доменов, и создание фишинговых сайтов) будут одинаковые, и в рамках круглого стола они были озвучены, приведу их:
0. Решить вопрос с SSL/TLS в стране, иначе проверить подлинность сайта не представляется возможным.
1. Заявления на регистрацию домена принимать только подписанными квалифицированной электронной подписью (КЭП).
2. Реализовать алгоритмы, аналогичные применяемым в услугах защиты бренда, по поиску доменных имен похожих на уже существующие. Направлять их на дополнительную проверку, как минимум. Можно даже начать с банального: если есть домен в зоне RU, при попытке регистрации такого же имени в другой зоне (SU, РФ и пр.) - уточнять, что то же юрлицо.
На мой взгляд п.1 уже будет вполне эффективным первым шагом.
Что еще можно предложить, пожалуйста, пишите в комментариях.
#РФ
Однако, в этой заметке хочется затронуть вопросы от представителей реального бизнеса, а их было примерно два:
1. Киберсквоттинг. Т.е. защита бренда компаний. Что делают регистраторы для того, чтобы ловкие ребята не захватывали доменные имена, релевантные крупным компаниям и не перепродавали их затем за бешеные деньги?
2. Фишинговые домены. Т.е. защита от появления доменов вредоносной направленности (по схеме тайпосквоттинга и т.п.), реализующие, например, воровство аутентификационных данных. Что делают регистраторы для того, чтобы подобные фишинговые сайты (пример, из последнего) не возникали в таком количестве, ввиду недопустимой простоты регистрации домена.
Короткий ответ на оба вопроса: регистраторы для решения проблем пп. 1-2 не дели ничего в 2001 году (мое первое место работы), ничего не делают сейчас, и не планируют. И для того, чтобы они что-то начали с этим делать, их надо обязать на уровне регулятора.
Дело здесь в том, что Регистратор - это коммерческая контора и, по большому счету, ему все равно с кого он получит свои $20 за домен, а чем больше регистрируется доменов - тем выше у него объем продаж. Поэтому, перекрывая какую-то долю потока регистрации доменов или как-то затрудняя процесс, что приведет к снижению регистраций доменов, Регистратор будет просто сокращать свои продажи, что, очевидно, экономически невыгодно. Поэтому здесь единственный инструмент - compliance, который надо потребовать со стороны госрегулятора.
Мероприятия по решению обеих обозначенных проблем (и захват доменов, и создание фишинговых сайтов) будут одинаковые, и в рамках круглого стола они были озвучены, приведу их:
0. Решить вопрос с SSL/TLS в стране, иначе проверить подлинность сайта не представляется возможным.
1. Заявления на регистрацию домена принимать только подписанными квалифицированной электронной подписью (КЭП).
2. Реализовать алгоритмы, аналогичные применяемым в услугах защиты бренда, по поиску доменных имен похожих на уже существующие. Направлять их на дополнительную проверку, как минимум. Можно даже начать с банального: если есть домен в зоне RU, при попытке регистрации такого же имени в другой зоне (SU, РФ и пр.) - уточнять, что то же юрлицо.
На мой взгляд п.1 уже будет вполне эффективным первым шагом.
Что еще можно предложить, пожалуйста, пишите в комментариях.
#РФ
Telegram
Солдатов в Телеграм
Вчера мне довелось побывать в Государственной Думе. В зале ЛДПР состоялся круглый стол "Практика противодействия кибератакам", аудитория - представители отрасли, как поставщики решений, так и их потребители. Хочется выразить слова благодарности компании Angara…
👍6🔥2
В ряде последних бизнес презентаций я использовал неочевидные картинки с облаками и лужами, и как обещал, в новом лонгриде публикую поясненния.
Если необходимость подъема технических уязвимостей до уровня бизнес-рисков (и проецирование бизнес-рисков на автоматизацию соответствующих БП) не очевидна или представляется сложной\ невозможной, пишите в комментариях, буду придумывать как обфусцировать (и можно ли вообще) пару реальных проектов из практики, либо придумывать синтетику в качестве иллюстрации. Но, по-моему, все очевидно, понятно, ничего сложного.
#vCISO #управление
Если необходимость подъема технических уязвимостей до уровня бизнес-рисков (и проецирование бизнес-рисков на автоматизацию соответствующих БП) не очевидна или представляется сложной\ невозможной, пишите в комментариях, буду придумывать как обфусцировать (и можно ли вообще) пару реальных проектов из практики, либо придумывать синтетику в качестве иллюстрации. Но, по-моему, все очевидно, понятно, ничего сложного.
#vCISO #управление
Дзен | Статьи
Риски бизнес-процессов и уязвимости автоматизации
Статья автора «REPLY-TO-ALL Information Security Blog» в Дзене ✍: Корпоративные бизнес-процессы (БП) определяют работу компании.
🔥4
Друзья из БИзона опубликовали презентации и фотоотчет с крайнего митапа, посвящённого облегчению работы аналитиков в SOC. Там есть много интересного для автоматизаторов и методологов.
#MDR
#MDR
Telegram
BI.ZONE
👍8🔥1💩1
Пресс-релиз о разрыве отношений повышает риск мгновенной кармы
В бизнес-мире хорошей практикой являются анонсы о партнерстве, возникновении отношений потребитель-поставщик, вот один из множества примеров.
Подобные пресс-релизы хорошо характеризуют поставщика: его предложение такое хорошее, что оно выбирается столь успешным потребителем и т.д. и т.п. А вот официальных публикаций о разрыве отношений не так много(ну, разве что вот пример , но не из ИБ, да и я, возможно, предвзят к "Студии Лебедева" , работал с ними в 2007, надеюсь, сейчас они достигли зрелости) , неверно, на то есть объективные причины, а, вполне возможно, факт того, что кто-то из заказчиков остался без защиты, вообще стоит скрывать. Но надо понимать, что в современном мире скрыть факты разрыва отношений крайне сложно, а сам факт этого повышает риск быть атакованным.
Немалая доля клиентов пришла в MDR после инцидентов: их пошифровали, украли данные и слили, и пр. , потом их полечили, а в качестве кибергигиены\кибериммунитета, для неповторения подобного инцидента, предложили MDR.
И, вроде как, все было хорошо, кибериммунитет работал, инцидентов с материальным ущербом не случалось, может, потому что любая атака имеет стоимость, а наличие MDR значительно повышает эту стоимость, и атака перестает быть рентабельной, ибо есть другие "низко висящие фрукты"(Чтобы убежать от медведя, не надо бежать быстрее медведя. Нужно бежать быстрее соседа (с) ) , а, может, просто везло.
Однако, после разрыва отношений потребитель самостоятельно переводит себя в ряд "низко висящих фруктов", в состояние без защиты, как раз в то самое состояние, когда у него уже случался инцидент, после которого его полечили и предложили профилактику в виде MDR.
Практика показывает, что после успешной чистки инфраструктуры, мотивация атакующих не меняется, поэтому, при прочих равных, они снова вернутся повторить прошлый успех, а пресс-релиз о том, что заказчик остался без защиты, вполне может послужить катализатором, дополнительным стимулом для атакующих - вероятно, это и является основным объяснением отсутствия пресс-релизов о разрыве отношений.
#пятница #MDR #vCISO
В бизнес-мире хорошей практикой являются анонсы о партнерстве, возникновении отношений потребитель-поставщик, вот один из множества примеров.
Подобные пресс-релизы хорошо характеризуют поставщика: его предложение такое хорошее, что оно выбирается столь успешным потребителем и т.д. и т.п. А вот официальных публикаций о разрыве отношений не так много
Немалая доля клиентов пришла в MDR после инцидентов: их пошифровали, украли данные и слили, и пр. , потом их полечили, а в качестве кибергигиены\кибериммунитета, для неповторения подобного инцидента, предложили MDR.
И, вроде как, все было хорошо, кибериммунитет работал, инцидентов с материальным ущербом не случалось, может, потому что любая атака имеет стоимость, а наличие MDR значительно повышает эту стоимость, и атака перестает быть рентабельной, ибо есть другие "низко висящие фрукты"
Однако, после разрыва отношений потребитель самостоятельно переводит себя в ряд "низко висящих фруктов", в состояние без защиты, как раз в то самое состояние, когда у него уже случался инцидент, после которого его полечили и предложили профилактику в виде MDR.
Практика показывает, что после успешной чистки инфраструктуры, мотивация атакующих не меняется, поэтому, при прочих равных, они снова вернутся повторить прошлый успех, а пресс-релиз о том, что заказчик остался без защиты, вполне может послужить катализатором, дополнительным стимулом для атакующих - вероятно, это и является основным объяснением отсутствия пресс-релизов о разрыве отношений.
#пятница #MDR #vCISO
👍8😁3🔥2