На память и в качестве небольшого отчета о прошлой неделе в отпуске подготовили минутное видео о том, как рождаются легенды. Приятного просмотра!

#здоровье

В вебинаре все хорошо с позиции расчета стоимости инцидента, когда он произошел (т.е. уже после TA0040), однако, намек о том, что стоимость инцидента может обосновывать стоимость инвестиций в ИБ не совсем корректен, и напоминает традиционную "пугалку". Проблема тут простая, но не имеющая простого решения, – вероятность наступления инцидента. Например, стоимость инцидента 9/11 колоссальна, однако, вероятность его наступления близка к 0, а произведение его ущерба на его вероятность слабо предсказуемо и поэтому с ним сложно сравнить потенциальные инвестиции в безопасность, в итоге под это можно обосновать что угодно от полного бездействия до безграничной паранойи.

Исключим форс-мажоры, и рассмотрим в общем случае: задача наших, обосновываемых ущербом, контролей ИБ – максимально затруднить продвижение злоумышленника от TA0043 до TA0040. Причем, каждый наш контроль как-то снижает вероятность наступления инцидента (это "как-то" зависит от эффективности и результативности контроля, что также непросто оценить), вся совокупность контролей не приводит к нулевой вероятности, а произведение остаточной вероятности на ущерб (стоимость инцидента) – это остаточный риск, который Бизнесу надо принимать. Вероятность наступления инцидента посчитать сложно, если вообще возможно, так как мы, своими контролями ИБ, ею управляем только частично. Вторая составляющая вероятности наступления инцидента – возможности и мотивация злоумышленника, на что мы вообще никак не влияем, поэтому в своих оценках здесь лучше перезаложиться.

В общем, к сожалению, стоимость инвестиций в ИБ крайне опосредованно можно сравнивать с ущербом (но, на безрыбье...). И вся наша практика это просто доказывает: как правило, используются типовые контроли ИБ, их стоимость определяется размером ИТ-инфраструктуры (а бюджет ИБ – просто % от бюджета ИТ), а не не критичностью данных и стоимостью нарушения их безопасности (наступления инцидента), как надо бы по-красивому....

Итого,
1. BIA и оценка рисков - хорошие, старые как вся ИБ, проверенные временем, академические инструменты для оценки стоимости инвестиций в ИБ, ими и надо пользоваться. Чего-то современного лучше, я не видел. Напишите в комментариях, если есть какие-то новые хорошие методы. Кстати, в рамках BIA как раз придется оценивать ущерб и, если, вдруг, с этим будут сложности, можно посмотреть вебинар.
2. При оценке вероятности наступления инцидента рассматриваем компетентного и мотивированного злоумышленника. Самое простое - заказать пентест с хорошим ТЗ.
3. Можно, конечно контроли ИБ делать самому, но на этом лучше сэкономить и по-максимуму передать в ИТ, а что точно надо делать подразделению ИБ, так это - измерять эффективность и результативность внедренных контролей ИБ, постоянно, и придумывать мероприятия по их повышению (эффективности и результативности)

#vCISO

Из-за того, что в Архызе не все хорошо с размещением: нормальные гостиницы, типа Флоры, стоят очень дорого, вчера осваивали новый метод.

Выглядит это так:
4:30 - подъем, 5:00 выезд из Кисловодска;
7:55 - на месте (парковка в Романтике);
8-8:30 - завтрак в кафе Борд, но лучше брать бутерброды и кофе с собой (в "Ай да Еда" завтраки нам показались ужасными, хотя весьма бюджетно)
8:30 где-то до 12-13 - катались;
13:00 - обед в «Трамплине»
14:00 - уехали
По пути, попили отличный кофе в «Cukur» в Зеленчукской
В Кисловодске были в начале 6-ого вечера

В целом, рабочий вариант, если для вас не сложно вставать в 5 утра, для меня - не проблема

Записи катания:
Strava
Skill

#здоровье

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

Почему можем не увидеть? Это связано с тем, что "инцидент" в нашем случае должен быть обязательно "actionable", т.е. по инциденту должен существовать какой-либо план реагирования на него, поэтому если EPP эффективно предотвратил ВПО и больше поделать нечего - это не будет инцидентом и не попадет в статистику. Однако, если есть что поделать, например, а) пообщаться с пользователем, чтобы не кликал по ссылкам или не открывал вложения, б) попатчить сетевые службы на периметре, в) пообщаться с пользователями, чтобы поаккуратнее с флешками, или внедрить решение по контролю съемных носителей, г) пообщаться с админами, чтобы не админили сервера psexec-ом с передачей пароля в командной строке и многое-многое другое - это будет считаться инцидентом, хотя, атака была и неуспешна, а мероприятия по реагированию влияют на конкретно этот инцидент опосредованно

Эх, угораздило же меня вчера оставить на сайте автосервиса заявку на обратный звонок! Обратного звонка так и не последовало, а вот спама сегодня налетело знатно!

Аккуратнее с оставлением своего номера на всякого рода сайтах! Причем, опять же по опыту, "доброе имя компании" едва ли является гарантом спокойствия. Все свои ипотеки я брал в топ-5 банков РФ и буквально все эти сделки не проходили бесследно: мне звонили страховые, мне звонили другие банки с релевантными предложениями, типа "рефинансировать". Аналогичные истории с приобретением машин: предыдущих авто уже нет, но по ним по-прежнему звонят с предложениями застраховать или пригласить на техническое обслуживание на индивидуальных условиях.

Будьте внимательны!

Мужчина становится мужчиной только после того, как он завоюет любовь женщины.

С праздником, мужчины!

Для составления объективной картины действительности хорошим методом является потребление большого количества информации из разных источников. Это относится и к составлению понимания ландшафта угроз, которое так важно для объективной оценки рисков. Однако, важно понимать, что Аналитический отчет MSSP - это отражение его видения, сильно искажающее действительность. Эти искажения нужно понимать, и, при построении собственного мнения, уметь их нивелировать. Ввиду этих же искажений нельзя просто сопоставлять отчеты разных поставщиков, а сами отчеты должны отвечать на многие вопросы, в том числе и по методологии, чтобы их контент был в принципе интерпретируемым.

Обо всем этом рассуждал в своей новой статье об искажениях\отражениях MSSP в своих аналитических отчетах.
https://dzen.ru/a/ZdcunHptMCiNsNeE

#vCISO

Когда клиентская база достаточно большая, дополнительный объем в 10к новых эндпоинтов в мониторинг не требует дополнительных ресурсов. Однако 100 клиентов по 100 - совсем не одно и то же, что 10 клиентов по 1000 или, тем более, 1 клиент с 10 000 эндпоинтов! И причина тому - необходимость адаптации. После этой заметки, думаю, станет понятнее почему малое количество крупных клиентов на долго проще в обслуживании множества мелких с короткими периодами обслуживания.

99% ложных срабатываний связаны с особенностями заказчиков, поэтому для огромного количества правил обнаружения есть клиентские фильтры, - чем больше клиентов, тем больше клиентских фильтров. Фильтрами надо управлять, отслеживать что они фильтруют фолсу и, что еще важнее, - не фильтруют инциденты. В общем, создание фильтра - это только начало, далее следует нелегкий процесс управления клиентскими фильтрами. Средняя продолжительность адаптации одного клиента среднего размера (до 10 000 эндпоинтов) составляет 1-2 месяца, т.е. за это время большая часть его контекстной фолсы будет отфльтрована (== фолсящие на сети клиента правила будут адаптированы), далее эта адаптация будет продолжаться постоянно, догоняя процесс управления изменениями в ИТ-инфраструктуре клиента. На период адаптации трудоемкость по обработке алертов с клиента увеличивается примерно в 2 раза, как раз за счет необходимости реализации адаптации (== фильтровать контекстную фолсу).

Понятно, что если фильтры не делать, то контекстной фолсы будет очень много, и это будет сильно снижать эффективность работы команды: все будут заняты разбором ложных срабатываний, что не может не отразиться на усталости\утомленности и, в конечном счете, результате работы. Но это в долгосрочной перспективе. В краткосрочной перспективе мы имеем х2 трудоемкости без очевидного выхлопа по качеству обнаружения.

Простота подключения к MDR делает возможным множество пилотов, поэтому, усредненно по году по миру 20-30% объема мониторинга - пилоты. Продолжительность пилота - 1 месяц... и здесь следует заметить, что а) поскольку не всегда есть уверенность, что клиент после пилота станет коммерческим клиентом, адаптация на пилоте делается по-минимуму, не в указанные выше х2 трудоемкости, б) месяца пилота недостаточно чтобы закончить процесс адаптации, в) даже если уложимся в месяц, увидеть результат в долгосрочной перспективе - не судьба😔. Как результат, фолсы на пилоте очень много и с ней приходится мириться, ввиду всего описанного. Следовательно, совокупная конверсия детектирующей логики на пилотах ощутимо ниже, а если пилоты берутся во внимание при расчете общей конверсии по всем клиентам (и пилотам, и коммерческим), то описанная ситуация с пилотами приводит к снижению общей конверсии.

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

Поэтому, чтобы популярность техник у разных провайдеров была сравнима, нужно чтобы сенсоры в частности и возможности по обнаружению вообще были одинаковы, хотя бы примерно

За вычетом геополитического налёта и аттрибуции, достаточно полезное чтиво

https://www.ncsc.gov.uk/news/svr-cyber-actors-adapt-tactics-for-initial-cloud-access

Не могу не поделиться нашим поздравлением друг друга с 238 мартраля!

Есть мнение, что надо строго разделять работу и неработу, я с этим согласен лишь отчасти. Как бы мы не пытались быть сдержанными и формальными, все равно отношения в коллективе не всегда удается ограничить исключительно производственными. Поэтому наше человеческое, наши психологические особенности влияют (а во многом и определяют!) на то, как мы работаем.

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

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

Можно сказать, что сегодня юбилей альбома "The Time of the Oath" группы Helloween. Альбом увидел свет 29 февраля 1996 года, 28 лет назад. Не так много вещей в Helloween мне нравились, но среди них есть немало и из "эпохи Дериса", и из "эпохи Киске". И вроде бы ничего особенного, мне нравится совершенно разная музыка, причем увлечения заметно меняются во времени, но неизменно близкими остаются композиции с историей.

У меня есть замечательный друг, вокалист-природник, Олег Савченко. Мы любили собраться в его гостеприимном доме, попеть в караоке. И где-то в 2013-2015 Олег напомнил мне о Forever and one, которую я слышал и ранее, но как-то подзабыл. Вот тут я и решил ее разучить.
Оригинальная тональность мне не удобна, на высоких нотах получалось грязновато, но, пониженная на 2, оказалась вполне рабочей. И в январе 2016, аккурат в 20-летний юбилей альбома, я записал ее в студии на конкурс "Роснефть зажигает звезды" (тогда я работал в Роснефти, а, имея с детства не реализованные мечты театрального актера, и тогда и сейчас стараюсь не пропускать возможность поучаствовать во всякого рода самодеятельности).

Итак, вашему вниманию предлагается мой вариант Forever and one 8-летней давности, не судите строго, зато от души. В комментарий к этой заметке заброшу отдельно аудио-дорожку.

#музыка