Сегодня 12 апреля, День космонавтики. В этот день 12 апреля 2001 года вышел восьмой студийный альбом группы "Ария", последний альбом с Валерием Кипеловым в качестве вокалиста. Альбом, после которого я перестал слушать "Арию", а слушать "Кипелова" я до сих пор так и не начал. Активное увлечение Арией пришлось на мои институтские годы, и сейчас, слушая песни тех лет, я вспоминаю свое студенческое прошлое.

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

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

#музыка

От Waterfall до Snowball

Несмотря на то, что книжки про гибкую разработку уже давно стали классикой, а agile всеми интерпретируется как "абсолютное добро", вот и у Сбера есть целый Agile центр (правда, закрылся, видимо, они agile уже повсеместно внедрили и необходимость в Центре пропала) и пишут они о нем много теплых слов, на реальном производстве нередко встречается классический waterfall, ровно такой, как мне преподавали в институте, аж в 1996 году, иногда, для осовременивания, этот waterfall снабжают итерациями (спринтами), видимо, это и есть основное достижение гибкой разработки.

В 1996 году в институте я проходил жизненный цикл информационной системы: она разрабатывается (по waterfall-у), внедряется, эксплуатируется и выводится из эксплуатации (или что-то вроде того). Однако, за все свои 25 лет работы, ровно такого цикла я никогда не видел, а было примерно так: разработка - внедрение - эксплуатация с постоянной доработкой - .... (видимо, я уже поколение CI/CD). И это нормально, ибо ничто не стоит на месте и нам постоянно нужно дорабатывать используемую систему, чтобы она лучше отражала постоянно изменяющуюся действительность (да и закон диалектики утверждает, что совершенству нет предела). А вот для "постоянной доработки" waterfall совсем не пригоден, как минимум, потому, что за время пути собака точно подрастет. Но детали еще хуже!

Мы все хотим функционала - чем функциональнее наша система, тем лучше! А еще мы хотим, чтобы весь функционал тестировался, поэтому мы хотим много сценариев тестирования! А чтобы иметь постоянную уверенность, что наш новый функционал ничего не отломал, мы хотим проводить регрессионное тестирование, постоянно! Чем больше у нас функционала и тестов, тем дольше у нас регресс. Бесконечно сложная система, с бесконечно хорошим покрытием тестовыми сценариями будет иметь бесконечно долгое регрессионное тестирование, которое рискует не поместиться ни в одну итерацию (не забываем, что прогрессивный waterfall имеет итерации). Но и это еще не все!

Чем больше функционала, и чем он сложнее, тем больше дефектов! А исправление дефекта тоже может что-то поломать, поэтому после исправления бага объяснимо желание проведения полного регрессионного тестирования. Бесконечно сложный функционал и так имеет бесконечно долгий регресс, но надо не забыть добавить к этому бесконечное количество багов! Хорошо, что математика тут за нас - умножая бесконечность на бесконечность, мы получаем все ту же бесконечность, а не супер-бесконечность или мета-бесконечность, однако, легче от этого не становится, а ситуация нарастает как снежный ком.

#dev #пятница

Первые впечатления от GT5 Pro и спорт ЗОЖ на КМВ (со ссылками на локации)

Мои старенькие Huawei Watch GT2e я угробил, предположительно в Итальянских термах: сначала у них потерял цветность экран, затем, во время плавания в бассейне они стали постоянно перегружаться, в текущем состоянии добавилась неисправность нижней кнопки (ее нажатие ни к чему не приводит). Кроме Итальянских терм, вполне возможно, сработало то, что я позволял себе нажимать кнопки в воде, что, оказывается, "нужно избегать", цитата из справки:

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

Идентичные противопоказания написаны и для GT2e и GT5 Pro. На протяжении всей эксплуатации GT2e я постоянно управлял им под водой (переключение режимов отображения тренировки) и все было нормально.

GT 2e были простецким, но хорошо работающим девайсом, о котором очень лестно отзывался Роб (вообще, у Роба на канале очень много обзоров на самые разные устройства, если выбираете - обратите внимание)

О GT5 Pro Роб отзывался значительно менее воодушевленно, даже утверждал, что они проигрывают в точности измерения пульса предыдущим моделям, в частности, GT3. У меня GT3 не было, но в отличие от прежних GT2e, GT5 Pro, как будто, точнее измеряет пульс, и во время бега, и во время плавания: у меня сложилась сильная уверенность, что GT2e завышал пульс, частенько мне показывая 176+, что в моем возрасте и при той нагрузке, да и по самочувствию, однозначно не соответствовало действительности. С GT5 Pro подобного я пока не наблюдал - что бы не говорил Роб, GT5 Pro измеряют пульс точнее, чем GT2e.

Однако, на днях в Суворовских термах, я, все-таки, победил GT5 Pro! Подробности моей Альтернативной тренировки здесь, а если кратко: я ставлю тренировку "Другое" и на основе пульса принимаю решение, что пора мне охладиться или, наоборот, погреться. GT2e превосходно переживали температуру горячего бассейна выше 45 градусов. В Новых Суворовских термах, температура воды была 42 градуса, ну, может, максимум 43, но при этом GT5 Pro стабильно ругались на перегрев и сбрасывали тренировку, приходилось ее запускать заново, итог - на картинке. В общем, в 100-градусную баню с ними точно нельзя, минеральной воды (щелочная) в 43 градуса им достаточно. Забив на мнение Роба я остановился именно на Pro, так как там получше материалы - это позволяет надеяться, что часы послужат подольше (хоть я и не настоящий экстремал, но все-таки...), а еще у Pro потрясающая быстрая зарядка, и батареи хватает на 2 недели (если не бегать часто с GPS).

Опыт эксплуатации GT2e с 2020 по начало 2025 показывает, что китайский уплотнитель живет примерно 4 года, а потом часы теряют герметичность, что приводит к их концу, посмотрим, доживут ли GT5 Pro до 2030...

#здоровье

Кисловодск. Путешествие во времени

Альберт Эйнштейн говорил:

Теоретически, теория и практика — одно и то же, на практике — совсем разные вещи

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

Прогуляться по Курортному бульвару как Ахматова или Маяковский, ощутить себя художником-передвижником вместе с Ярошенко, и на его даче, и даже попробовать свои силы в акварельном натюрморте, а вечером того же для - попытать удачу в казино, как в свое время любила Кшесинская, но в нашем случае казино - винное, что позволит и расслабиться и познакомиться с замечательными местными винами. Утром следующего дня - поездка в горы, ну как же без них (!) вместе со Станиславским, а после - настоящее застолье, "Пели и пили", - как вспоминал Шаляпин, но в нашем случае - с лекцией о традициях народов Кавказа. В день отъезда - прогулка по Кисловодскому парку на электромобильчике.

#здоровье #искусство #история

Кстати, если, вдруг, вы будете в Сеуле в период с 14 по 17 мая, то я здесь.

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

Пишите, если будете на мероприятии, точно найдем возможность пересечься!

#MDR

ИИ как доверенный посредник

Интереснейшая статья попалась (прямая ссылка на PDF). Я уже рассуждал о плохой пригодности ИИ для криптографии, однако в данном конкретном сценарии ИИ выглядит перспективно.

Доверенный посредник - это независимая сторона, которой доверяют все участники взаимодействия. В замечательной книжке "Прикладная криптография" Брюс Шнайер использовал термин TTP (Trusted Third Party), который удобно набирать не переключая язык клавиатуры, им же буду пользоваться и я. TTP может выполнять различные функции: аутентификация, арбитраж, распределение ключей, и др. За примерами далеко ходить не надо: в протоколах цифровой подписи TTP может выступать гарантом подлинности, в криптографии с открытым ключом ТТР - это удостоверяющий центр, в протоколах электронных платежей ТТР не допускает повторное расходование и выполняет общий арбитраж - подтверждает корректность выполнения протокола.

Но вернемся к статье - авторы решают проблемы конфиденциальности при использовании ТТР. Например, если Анна и Борис хотят узнать кто из них живет дальше от Москвы - это можно сделать через ТТР, но одновременно, они не желают раскрывать ТТР свои места жительства - здесь помогут криптографические протоколы, ограничивающие раскрытие данных (например, доказательство с нулевым разглашением). Однако криптографические методы имеют ограничения по масштабируемости при использовании в сложных приложениях. Для решения этой "тяжеловесности" криптографии, авторы вводят Trusted Capable Model Environments (TCME) - ML-модели, работающие с жёсткими ограничениями на ввод/вывод, контролем потоков информации и отсутствием состояния. Использование TCME удобно: Анна и Борис, решив свою проблему через посредника TCME, могут затем ее уничтожить, могут взять TCME к себе в лабораторию и проверить ее там миллион раз, тем самым доказав себе "честность" и "непредвзятость". В статье приведены примеры где ИИ в качестве ТТР реально полезен.

Все это пока смотрится немного как научная фантастика (может, поэтому и привлекает 😁), однако, повторюсь, выглядит перспективно и за этим стоит последить.

#crypto #ml #книги

Что отличает людей от ИИ? Способны ли машины создавать креативные идеи, и что такое креативность вообще? Как-то я рассуждал на тему может ли ИИ уничтожить Человечество, но не уточнял что понимается под "уничтожить". Как вы относитесь к продуктам из вторсырья, будете ли употреблять блюда, приготовленные из отходов (даже если будут все нужные заключения), а должны ли мы считать старые идеи, пережеванные ИИ, новыми? А сами-то мы, люди, как создаем новое, точно ли не переиспользуем что-то созданное ранее? А как вообще мы понимаем окружающий мир, и как выглядит наше непонимание, и почему мы можем не понимать? А почему это же наше непонимание не может распространиться на креативные идеи, ведь чрезвычайно креативная идея может быть не понята и не оценена....

Обо всем этом я рассуждал в новом лонгриде Креативность.

Когда-то мы все вычисления могли сделать в уме, потом - с помощью бумаги и карандаша, позже появились какие-то справочники, типа таблиц Брадиса (и ваш покорный слуга их застал), таблицы были вытеснены калькулятором, затем - компьютером с алгоритмическим ПО. Затем мы попытались развить матстатистику и, перенося прошлое на будущее, получили машинное обучение, а сейчас в качестве инструмента нам доступен генеративный ИИ.

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

#искусство #ml

На днях обсуждали с друзьями процессную модель операционного подразделения ИБ, и принципиальный вопрос:

Как выглядит идеальный баланс между инструкциями, персональными взаимодействиями/наставником, общими ретро,...?

Поток мыслей по этому вопросу записал в свежем лонгриде "Формализация"

Очень приветствуется ваш опыт решения поставленных вопросов, ваша граница красоты\баланса.

#управление #vCISO #MDR

Я уже писал про лекции Ангелины Дроновой и физически был на мероприятиях с ее участием. И вот, с 15 по 18 мая Ангелина снова будет в Кисловодске!

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

В период с 15 по 18 мая участники получат возможность прожить историю самостоятельно:
- пройтись по улицам, зайти в Нарзанную Галерею, подобно Маршаку, Зощенко, Тэффи, Мережковскому и Гиппиус, Рахманинову... да вообще, всем!
- вспоминая азартную Матильду Феликсовну - сыграть в казино, а за одно, ознакомиться с прекрасными экземплярами местных вин;
- попробовать настоящую кавказскую кухню, как точно делал Чехов;
- испытать свои художественные таланты в гостях у Передвижника Николая Ярошенко.

Кто меня читает, может заметить, что подобное путешествие во времени я уже делал (по ссылке - коротенький видео-отчет о том, как это было), и с удовольствием повторил бы, если бы не необходимость участия в мероприятии.

А у вас, если, вдруг, есть возможность, обязательно присоединяйтесь, не пожалеете!
(по-моему места еще есть, но это не точно, уточнить можно здесь)

#искусство #история

Мой старый добрый знакомый, Дэн Батранков, видимо, ввиду обостренного чувства справедливости, не на шутку озадачился вопросом сравнения XDR и SIEM, что отразилось в следующих многочисленных артефактах: заметка Отличие XDR от SIEM, а также презентация на SOC Forum 2024, доступная по ссылке.

Терминология - безграничная почва для бесконечных дискуссий, я это прекрасно понимаю, но Денис спросил мое мнение, а я стремлюсь не отказывать друзьям, чем и объясняется эта и связанные публикации.

Несмотря на то, что в следующем году уже 10 лет как я работаю в поставщике решений, все еще большую часть своей карьеры я провел в заказчике, где, как раз отвечал, в том числе, и за внедрение решений ИБ. А перед внедрением я всегда проводил сравнительный анализ, как правило, основанный на пилотировании в лабораторных условиях. Т.е. в моей картине мира выбор решения основан на степени его соответствия функциональным требованиям: соответствует - берем, не соответствует - ищем дальше, но никак не исходя из его названия (тем более, в маркетинговых листовках самого вендора). Поэтому, в общем-то, мне все равно кто что называет SIEM-ом, а что XDR-ом, в моем случае я бы выбирал исходя из функционального тестирования в лабораторных условиях, приближенных к реальной эксплуатации.

В предлагаемой вашему вниманию таблице я собрал различия SIEM и XDR, изучение которых должно навести на следующие мысли:
- и SIEM и XDR - нужные решения, так как закрывают немного разные сценарии
- XDR не является развитием SIEM, обратное тоже не верно
- идеальное решение можно достичь комбинацией

При этом, я не исключаю (более того, считаю это логичным) построение XDR на базе SIEM, так как если SIEM умеет работать с неструктурированными логами, то с предопределенной телеметрией у него точно получится. Широкие возможности по автоматизации на базе XDR как раз и обусловлены предопределенностью и структурированностью обрабтаываемой телеметрии. "Сырые" (== оригинальные, в первозданном виде) логи ИС, предназначенные для ручной обработки админами, - именно для работы с такими данными и придумывали SIEM, а необходимость корреляции событий разных ИС создала потребность в нормализации. Хранение сырых логов долго и централизовано требуется и регуляторами и для ретро (ну мы же не хотим, чтобы наша система умерла вместе со всеми своими логами, поэтому логи надо уносить) - это тоже функция SIEM. Ранее я упоминал про Log management, и эта заметка отчасти повторяет те же мысли. Больше различий я пособирал в табличке. Как всегда ваши предложения и критика приветствуются!


#пятница #vCISO #MDR

16 мая в 11:00 (MSK) мой коллега Алексей Пешик из команды SOC Consulting обсудит тему ИИ в кибербезе.

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

ИИ - это сложное решение, а Алексей - эксперт по доведению сложных решений до получени ценности заказчиком.

Регистрируйтесь!

#ml #vCISO

Долгий перелет из Москвы в Сеул (слайды и комментарии к ним, а также заметки при поготовке к панельной дискуссии, еще выложу) позволил прочитать книжку, и она - не заслуживает упоминания в этом блоге, но данные обещания надо выполнять, поэтому пишу эту заметку.

Как и ожидалось книжка очень предвзята и смотрит на вещи однобоко:
- США, Британия и Израиль представлены как "жертвы" или\и "защитники", а Россия, Китай и Иран – как главные злодеи. Она настолько пропитана пропагандой, что нередко вызывала улыбку умиления, а, порой, и смех в полный голос (действительно, наиболее смешные шутки произносятся с серьезным лицом);
- очевидные киберпреступления – Stuxnet (атака на Иран), EternalBlue и прочие (утечка Shadow Brokers, приведшая к WannaCry), Doqu, Duqu 2.0, Equation Group (связанная с NSA) – всё это либо подаётся как "необходимая защита", либо откровенно оправдывается без капли сомнения, типа, так и надо 😂;
- несмотря на то, что книга издана в 2020, продолжение традиции Equation - Project Sauron (Remsec), вообще не упоминается в книге. А это принципиальное событие на рынке ИБ, ибо, есть мнение, что ровно после этой публикации антивирус Symantec перестал существовать на B2B рынке, видимо, нельзя было им это детектить...., но не будем множить слухи 😁

В конце книги приведены Acknowledgments и Notes, беглый просмотр которых объясняет столь низкую объективность изложения: Перлрот опирается на интервью с бывшими сотрудниками американских спецслужб и кибербезопасности, которые, естественно, всячески оправдывают свои действия. Книга рассчитана на американского читателя, чьи чувства оскорблять не хочется (а можно и в бан попасть, демократия - она такая) и которому проще думать, что "мы хорошие, а они - плохие".

Краткий вывод из первой части моей заметки (сразу следом будет продолжение, более предметное), что книга полезна для понимания западного взгляда на кибервойны, но её нельзя считать объективной, так как она полностью игнорирует гипокризию США, которые сами создают в огромных количествах самые опасные образцы кибероружия, и первые начали это делать, но при этом обвиняют всех вокруг.

#мир #книги

Прямо с пролога Перлрот начинает излагать правильные нарративы, поэтому очень быстро (уже к первой главе) вырабатывается способность фильтровать всю эту пропаганду, читать между строк и связывать изложенные факты (благо, откровенного вранья в книге я не встретил, но есть слухи и домыслы авторов). Для примера приведу лишь одну из историй, но она хорошо иллюстрирует то, что я хочу сказать. На картинке - страница, где автор рассказывает об Operation Shotgiant, когда NSA взломало Huawei. "Официальная" версия этого влома - Huawei представляет угрозу из-за связей с китайскими властями и потенциальных бэкдоров в её оборудовании, однако, сама Перлрот пишет, что цель NSA - внедрить свои бэкдоры в оборудование Huawei. Факт того, что NSA допускает, что китайская компания шпионит в пользу китайского правительства означает, что с точки зрения NSA шпионаж американского вендора в пользу США - абсолютная норма. Это действительно так, поскольку Microsoft, Google, Apple – участвуют в программах слежки (FISA 702, CLOUD Act), поэтому в продукцию этих вендоров даже бэкдоры, как будто, не надо ставить, они и так обязаны сливать данные спецслужбам США, чтобы соответствовать. Но несложно догадаться, что бэкдоры там тоже точно есть, ибо, как мы знаем из истории, вскоре после скандала с Operation Shotgiant Huawei оказалась под санкциями 🙈 Действительно, отказ от внедрения американских бэкдоров - это неCompliance!

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

Все, приведенные в книге, ящики Пандоры открыты именно США (с ужасом вспоминаю историю Хиросимы и Нагасаки, при очевидном отсутствии военной обоснованности), и это явно следует из книги, а нелепые оправдания таких действий вызывают улыбку и смех, что делает чтение для тех, кто видит лес за деревьями, еще более увлекательным. Как отмечал в первой части этой заметки, книгу не рекомендую 😂

#мир #книги

А помните я как-то, почти год назад писал:

- DLL Hijacking - фактически, непопулярный сценарий загрузки DLL в процесс, напишу об этом чуть более подробно в отдельной заметке

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

Подробно написать в отдельной заметке я так и не успел, но вот на PHD будет доклад нашей коллеги, Анны Пиджаковой, из команды машобуча, Разработка ML-модели для детектирования DLL Side-Loading, где, уверен, Аня все подробненько расскажет.

#MDR #ml

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

Но что если SOC нашел legacy-систему без документации? Надо проанализировать архитектуру, выявить возможные вектора атак, покрыть релевантными детектами. А если таких нестандартных систем — не одна, а десять? Правильный подход к мониторингу источников известен, но на практике он требует много времени и глубокого понимая системы.

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

Аномалии аутенификации:
— Brute Force
— Password spraying
— Sharing creds
— The first logon to host (+ неуспешные попытки)
— The first logon from host (+ неуспешные попытки)
— Отслеживание профиля приложения клиента, которое использовалось для логина: отпечаток браузера для web, SQL-клиент для БД, толстый клиент для приложений и т.д. (вне профиля = алерт).

Манипуляции с привилегиями:
— Добавление/исключение в группу/из группы
— Изменение прав доступа
— Массовая блокировка/отключение администраторов
— Создание УЗ

Сеть:
— Изменение количества peer-ов
— Использование нетипичных для системы сетевых сервисов

Процессы и настройки:
— Выгрузка защищаемых ресурсов вне профиля
— Резервное копирование вне профиля
— Управление резервным копированием вне профиля
— Администрирование функций безопасности
— Удаление журналов аудита безопасности

Используя подобный подход, можно покрыть 11 из 14 тактик атак MITRE, что очень неплохо для незнакомой системы.

Более подробно о таких универсальных приемах Threat Hunting — слушайте завтра в докладе нашего эксперта Николая Советкина «Стандартные правила для нестандартных источников» на конференции PHDays (23 мая, 12:15). Для тех, кто не сможет присутствовать – обещают и трансляцию, и запись.

Приятно видеть, что наш с Денисом вебинар не остался совсем не замеченным и на наиболее значимой конференции по ИБ его упоминают! Очень приятно.

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

#MDR #vCISO