P&L атаки

Есть такой старый постулат, что все наши усилия в ИБ должны повысить стоимость атаки настолько, чтобы атакующему было неинтересно нас атаковать, чтобы P&L проекта атаки был отрицательным. Я не раз писал о том, что это утрверждение уже давно работает крайне плохо, однако, до сих пор в маркетинговых листовках и публикациях такое утверждение можно встретить. Вероятно, это объясняется тем, что никакие контроли безопасности (== никакие инвестиции в ИБ) не исключат полностью возможность атаки, и, как будто, порог нерентабельности атаки выглядит логичным компромиссом для объема инвестиций в эту бездонную бочку с названием "корпоративная ИБ".

В современных условиях "нерентабельность атаки" представляет собой не столько порог инвестиций в ИБ, а, скорее, создает состояние гонки, поскольку, как бы мы не напрягались, атаки все равно будут, только ущерб от них будет еще выше! Логика здесь следующая: чем лучше защищена инфраструктура, тем дороже атака - нужны серьезные исследования, разработка эксплоитов, инструментов атаки, возможно, лабораторные испытания этих инструментов, насколько успешно они обходят используемые СЗИ, в общем, чем выше безопасность, тем дороже атака - это полностью укладывается в постулат, с чего мы начали. Однако, атаки все равно будут, а раз они дорогие, то для обеспечения положительного P&L, профит от атаки должен быть еще больше. Профит атаки, как минимум, косвенно, отражается на ущербе для жертвы - высокий профит для атакующего означает большой ущерб для жертвы. В итоге получаем, вероятно, не очень очевидную, тем более, непопулярную, закономерность: чем больше мы инвестируем в ИБ, чем лучше защищена наша инфраструктура, тем больший ущерб мы получим от компьютерной атаки. И даже хуже: если инцидент все-таки дошел до ущерба, то все наши инвестиции в ИБ, будучи несостоятельными, тоже превращаются в ущерб...

В общем, повышением уровня безопасности мы в немалой степени сами провоцируем рост ущерба.

#vCISO #пятница

п. Яма 3 к.с. или "Как я провел лето"

Как на практике теория отличается от практики, так и наше фактическое путеществие имеет массу отличий от нашего плана, а именно:
1. Пройденный маршрут составил менее 50 км, проследить можно по Strava:
11.08.2025. День 1. 4,1 км
12.08.2025. День 2. 14,1 км
14.08.2025. День 3. 11,5 км
15.08.2025. День 4. 6,4 км
17.08.2025. День 5. 4,5 км
18.08.2025. День 6. 8,3 км
19.08.2025. День 7. Выброска катером от устья р. Тумча до п. Зареченск, ~30 км, уже в маршруте не учитывается

2. Стартовали ниже п. Перевенец, т.е. его не проходили и, предположительно, его наблюдали с ЛБ на стапеле. Стапель был преимущественно под автомобильным мостом, так как периодически лил неопределенный дождь.

3. До п. Яма шли без просмотра, поэтому с уверенностью сказать что из пройденного было пп. Падун, Водопадный, Кривой, Юрьев день, Мара и Красивый нет возможности, не сохранилось о них и фото- видеоматериала, надо было грести, а не снимать окрестную красоту 😢

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

С виду порог не выгядит страшно, как например, п. Котел (о нем в будущих заметках), однако, при прохождении можно столкнуться с некоторыми сложностями: мощная струя от камней ПБ при падении в яму поворачивает нос налево, что в совокупности с небольшой и, как будто, нестрашной, но задерживающей, бочкой последней ступени, создает риск оверкиля через баллон. В целом, когда мы уже груженые вещами, слава Богу, без пассажира, на следующий день отправились в дальнейший путь на нашем Рафтмастере К4, мы этот риск прочувствовали на себе - мой левый баллон ненадолго застрял в бочке, а ребятам на правом баллоне даже пришлось вывешиваться, но все быстро удалось исправить.

Делюсь видосами с наших покатушек:
1. Удачное прохождение - я и Петя (капитан нашей экспедиции) на Рафтмастере К2
2. Кривое, но тоже удачное я и мой старший, Илья, на том же Рафтмастере
3. Неудачное - я и Оля на легком РИГе
4. Удачное, как демонстрация возможности успешного прохождения и на легком РИГе умелым экипажем, Илья и Лиза.

Во всех моих проходах одинаковые ошибки:
- при падении в яму надо наклоняться вперед к баллону
- грести нужно интенсивнее
На РИГе забил на неотрегулированный правый упор - он и выскочил.

На фото к этой заметке - скриншот с видео нашего неудачного прохождения, который наш капитан назвал "Как я провел лето" 😂.

#здоровье

Сегодня снова зарегистрировался на Кисловодский марафон!

В этом году он получил дополнительное слово в название - MAYRVEDA, что совпадает с названием одного местного ЗОЖного отеля, посмотрим, повысит ли это качество организации, стартового пакета или вообще чего-то.

А вообще - это прекрасная возможность подарить себе праздник, а может, даже и с пользой для здоровья (главное, с дистанцией не промахнуться, а то когда регистрируюсь, рука невольно тянется к 21 км, но я жестко пресекаю в себе эти позывы)

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

Кто еще раздумывает, а, может, тоже приобрел слот, догоняйте!

#здоровье

Вышло фундаментальное исследование наших коллег из команды TI, основанное, в том числе, и на инцидентах обнаруженных в MDR и расследованных командой DFIR.

И хочетcя дополнить прекрасное интро Никиты Назарова следующими соображениями.

Разные коллеги по индустрии фиксировали разные активности, как будто, разных группировок и выпускали об этом разные отчеты. Но для того, чтобы видеть картину более-менее целиком необходимы: обширная клиентская база, широкая телеметрия и технологичные инструменты, квалифицированная экспертная команда. Перечисленное позволяет соединять точки линиями и, как точно подмечал Сергей Александрович, видеть большое "на расстоянье".

Коллеги старалиcь сделать отчет полезным для практиков, как говорится, Enjoy!

#MDR #kaspersky

Building a Successful Career in AI Cybersecurity

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

Ключевые выводы из доки
1. Конвергенция AI и Cybersecurity:
Документ подчеркивает, что искусственный интеллект и машинное обучение (ML) кардинально меняют ландшафт ИБ. AI используется как для усиления защиты, так и в качестве инструмента атак

2. п. 1 объясняет растущий спрос на специалистов:
Возникает новая категория ролей, таких как "Инженер по безопасности AI/ML" или "Специалист по безопасности данных", которые требуют уникального сочетания навыков ИБ и Машобуча.

3. Из доки можно выделить необходимые навыки и знания:
Технические навыки (Hard Skills):
- Понимание основ машинного обучения и data science.
- Знание языков программирования (Python, R) и умение работать с данными.
- Опыт работы со специализированными фреймворками и библиотеками (TensorFlow, PyTorch, scikit-learn).
- Глубокие знания в области ИБ
- Понимание облачных платформ (AWS, Azure, GCP) и их систем безопасности.

Soft Skills:
- Критическое и аналитическое мышление.
- Решение сложных проблем.
- Коммуникация (способность объяснять сложные концепции AI нетехническим специалистам).
- Любознательность и постоянное стремление к обучению.

4. Рекомендации по построению карьеры:
- Начните с основ: Получите прочную базу в классической ИБ (сертификаты типа CISSP, SSCP, CCSP очень приветствуются).
- Освойте Data Science: Изучите математику, статистику и основы машинного обучения через онлайн-курсы (Coursera, edX) или практические проекты.
- Получайте практический опыт: Применяйте свои знания в реальных проектах, участвуйте в соревнованиях по анализу данных (например, на Kaggle) или в открытых source-проектах.
- Вступайте в профессиональные сообщества, посещайте конференции и общайтесь с экспертами в этой области.

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

Документ позиционирует карьеру в сфере AI Cybersecurity как одну из самых перспективных и востребованных в технологической индустрии. Это поле требует непрерывного обучения, но предлагает уникальную возможность быть на передовой борьбы с киберугрозами нового поколения и формировать будущее цифровой безопасности.

#ml #саморазвитие #vCISO

Утечки - характеристика уровня Цифровизации!

Все много говорят о росте компрометаций и утечек, вот, например, видео в тему, утащенное у кого-то из сториз Телеги. Ну, а что это характеризует? Уровень цифровизации! Утечка означает, что бизнес-процесс оцифрован, а так как утекают практически любые данные, можно с уверенностью сказать, что цифровизация у нас близка к 100%, цель достигнута!

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

Что делать? Наверно, повторю то же, что писал про автоматизацию, но это не будет лишним.
1. цифровизировать нужно только то, где это принципиально необходимо
2. минимизировать количество зависимостей, тем более зависимостей от неконтролируемых разработок (например, не производимых в стране)
3. иметь наготове бэкап-план работы "без цифровизации", т.е. каждый цифровизированный процесс должен иметь BCP его работы в условиях когда цифровая его реализация невозможна (банально, нет света, связи, цифровые данные потерты)
4. чтобы п. 3 работал, полезно проводить учения, ну и DRP надо бы иметь, ибо, поработав с бумагой и карандашом, надо когда-то вернуться к привычной цифровой реализации

#управление #пятница #РФ