📦 Защита контейнерных сред
Облачные технологии и контейнеризация стали стандартом современной разработки, но вместе с гибкостью они принесли и новые вызовы для безопасности 👽.

Контейнеры и средства их оркестрации имеют специфическую архитектуру. В отличие от виртуальных машин, контейнеры разделяют одно ядро операционной системы хоста 🐧.

Пока освежал знания, написал ✍️ небольшую статью «Защита контейнерных сред» на ресурсе ISLib, где разобрал на что нужно обратить внимание системным администраторам и специалистам по ИБ.

Можно использовать ее как чек-лист по соответствующим уровням защиты:
🟢Защита образов контейнеров и их реестра
🟢Защита среды исполнения
🟢Защита оркестратора
🟢Сетевая изоляция
🟢Мониторинг и аудит

💬 Защита контейнеров должна прорабатываться как можно раньше (Shift Left Security) и не должна быть «пристройкой» в конце цикла разработки.

📖 InfoSec Context

📼 PAM не враг, а помощник администратора
Когда в компании вводят PAM (система контроля привилегированного доступа), то со стороны ИТ одна мысль: «Зачем эта прослойка, через которую всё будет тормозить. И зачем ИБ-ники её нам пихают?»🤯

Раньше так и было. Но за последние годы PAM-решения сделали большой шаг вперед и выросли с надзирателя до ассистента. Их фишки даже позволяют ИТ задуматься о необходимости такой системы.

1️⃣Удобный и быстрый менеджмент паролей
Современные PAM из коробки умеют создавать политику ротации паролей (например, менять пароль root каждые 6 часов). Системы сами при каждом запросе доступа проверяют срок действия пароля, а если он истек, то генерируют новый, меняют его везде (даже в AD) и только потом дают доступ.

Файлы с паролями на рабочем столе уходят в прошлое.

2️⃣Инструкции для новичков и контроль за их действиями
PAM умеет записывать сессию, и ничего не мешает использовать потом это видео как документацию🙌 для новичков.
При выполнении критических изменений кто-то из опытных экспертов может в реальном времени смотреть сессию и сразу вмешаться, если пойдёт что-то не так.

3️⃣Помним все ресурсы, и теперь к ним не нужен пароль
На портале PAM опубликован список доступных работнику серверов/приложений 🚀:
⏺RDP: ярлыки (постоянные или одноразовые), где PAM сам подставит пароль.
⏺RemoteApp: работа не с целым удалённым столом, а с конкретным приложением (например, клиентом БД) в привычном интерфейсе.
⏺SSH: применение готовых строк подключения без плясок с ssh user@server -i key.

4️⃣PAM для DevOps
Современный PAM позволяет⚙️:
⏺Генерация короткоживущих сертификатов. При получении временного сертификата можно логиниться без постоянного ввода пароля.
⏺Управлять доступами через REST API (создавать пользователей, выдавать права, менять секреты).
⏺Интегрировать с Ansible: запускаете плейбук через PAM, а он сам подставляет нужные учётные данные на целевые хосты.
⏺Встроить в CI/CD.

5️⃣Отказоустойчивость
Главный страх ИТ: «А что, если сам PAM ляжет? Как получить доступ?».
Однако современные решения предусматривают 🛡 кластеризацию и работу через балансировщик, а также возможности реализации экстренного доступа.

💬 PAM не только защищает, работая на ИБ, но и избавляет ИТ от рутины (ротация паролей, выдача прав), обеспечивает единую точку входа и дает инструменты для обучения и контроля (видеосессии, live-просмотр).

📖 InfoSec Context

🔐 OpenSSL обновился
Проект OpenSSL выпустил масштабное обновление до версии 4, в котором полностью отказался от устаревших механизмов ради повышения безопасности.

OpenSSL — это популярная библиотека с открытым исходным кодом, предназначенная для реализации криптографических функций 🔐 и протоколов безопасности, таких как SSL и TLS. Она широко используется для:
💬 шифрования данных и защиты сетевых соединений;
💬 создания и управления сертификатами безопасности;
💬 генерации ключей и цифровых подписей.

OpenSSL поддерживает множество алгоритмов шифрования, хэширования и работы с ключами. Библиотека применяется повсеместно 🏭 (веб-сервера, системы, VPN 🛡 и другие приложения, где требуется защита информации).

В новой версии:
⏺удалена поддержка устаревших протоколов SSLv2 и SSLv3, а также движков для сторонних криптографических модулей;
⏺отключены устаревшие эллиптические кривые в TLS;
⏺переработан API;
⏺добавлены проверки при работе с сертификатами, списками отзыва, идентификаторами ключей и при использовании FIPS-режима;
⏺добавлена поддержка "Encrypted Client Hello", китайских стандартов 🇨🇳 SM2/SM3, элементов постквантовой криптографии, новых алгоритмов хэширования и генерации ключей;
⏺удалены устаревшие утилиты и редко используемые компоненты;

💬 По итогу в OpenSSL 4.0.0 лишился предыдущих уязвимых компонент, и должен стать более защищённым. Но от нас теперь потребуется адаптировать свои системы/приложения к нему и отказаться от устаревших функций.

📖 InfoSec Context

👩‍💻 k8scout для контейнеризации
Kubernetes активно развивается и появляются новые open source инструменты, которые могут быть полезны для ИБ.

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

Инструмент работает в двух режимах:
🟢Наступательный режим (по умолчанию) — запуск из скомпрометированного модуля. Определяет права доступа и все доступные пути эскалации с вашего текущего положения.
🟢Режим проверки (--reviewer-mode) — запуск с SA только для чтения для аудита всей поверхности атаки кластера на предмет всех идентификаторов.

k8scout строит понятный граф 🏦 разрешений и с помощью алгоритма поиска пути находит реалистичные цепочки атак с учетом возможной эксплуатации текущей конфигурации среды контейнеризации.

При этом каждое обнаружение включает в себя идентификаторы техник по нотации MITRE ATT&CK, оценку риска и пошаговый план атаки с указанием задействованных узлов графа.

💬 Сейчас инструмент содержит 50 правил и имеет версию 0.1, что говорит нам о планах на развитие. Предлагаю последить и потестировать 🛠.

📖 InfoSec Context

👹 Ошибка выжившего.
Во время Второй мировой войны пилотов бомбардировщиков ✈️ называли «смертниками» из-за уязвимости их самолетов. Американские ВВС 🇺🇸решили укрепить наиболее повреждаемые части самолетов, основываясь на данных вернувшихся машин. Однако это не увеличило их живучесть. Математик Абрахам Вальд заметил, что повреждения не критичны, и предложил укреплять неповрежденные части — кабину и двигатели. После укрепления этих частей самолеты стали более живучими.

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

⁉️ Аналогично, в ИБ можно совершить подобную ошибку при переоценке эффективности защитных мер. Например, если система не была взломана, делают вывод: «Наша защита работает». Но реальность может быть другой: атаку просто не заметили или злоумышленники просто не пытались. 👽

С другой стороны, еще возможен вариант, когда ИБ анализирует только громкие успешные атаки и готовится к ним, при этом другие успешные атаки могут быть не замечены или скрыты, что создает ложное ощущение, что «мы понимаем угрозы», хотя картина неполная🔎.

💬 Не обязательно на начальном этапе вписывать все невероятные варианты атак в свою модель угроз, но видится, что ее нужно пересматривать почаще.😵‍💫

📖 InfoSec Context

🏹 Реагирование на 0-day
Реагирование на новые трендовые уязвимости часто затруднено из-за нехватки информации. Важно вовремя узнать об уязвимости ⏳ и быстро определить, затронута ли инфраструктура, какие сервисы уязвимы и доступны ли они злоумышленникам.

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

Шаг 0. Инвентаризация внешнего периметра
Используем CMDB для учета и описания активов. Мы должны знать все торчащие наружу сервисы. Возможно применение внешних EASM-платформ для выявления уязвимых сервисов. EASM (External Attack Surface Management) платформы сканируют внешний периметр и могут выявлять уязвимости.

Шаг 1. Узнаем о новой уязвимости
Создаем свой процесс мониторинга бюллетеней безопасности, NVD, БДУ ФСТЭК, социальных сетей, СМИ и Telegram🌌. Возможно использование внешнего сервиса.

Шаг 2. Анализ уязвимости
Определяем продукт 🔎, функциональность, условия проявления, версии, способы входа и меры исправления. Мониторим наличие рабочих средств реализации уязвимости (PoC).

Шаг 3. Подтверждение наличия уязвимости
Определение наличия уязвимого продукта в ландшафте и применимость уязвимости для конкретной конфигурации 👨‍💻.

Шаг 4. Непосредственное устранение уязвимости
Применяем необходимые патчи и временные меры на период тестирования🐳. Временные меры могут включать настройку WAF, ограничение подключений, усиление логирования и др.

Шаг 6. Проверка устранения уязвимости
Проверяем установленные версии и артефакты деплоя 📝, сканируем внешние активы и анализируем логи.

Шаг 7. Оценка процесса
Оцениваем процесс с 0 по 6 шаг для анализа узких мест и его совершенствования, так как скорость массовой эксплуатации 0-day уязвимости уже очень быстрая.

💬 Реагирование на уязвимости потребует от нас комплексного подхода и постоянного мониторинга появления новых уязвимостей. При наличии финансирования можно положиться на внешние EASM-платформы, но выстраивание полного процесса внутри компании позволит также реагировать и на уязвимости внутри периметра.

📖 InfoSec Context

Друзья, с праздником!

📖 InfoSec Context

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

В условиях стремительного развития ИТ и оптимизации бюджетов ИБ, крайне важно учитывать, что:
⏺Приоритизация важнее количества
Уязвимостей много, но эксплуатируются лишь некоторые 📉. Поэтому важно первоначально фокусироваться на тех, которые уже используются в атаках, а возможно и соответствуют тактикам конкретных групп.
⏺Какие угрозы реальны
Безопасность должна строиться вокруг реальных угроз (групп атакующих, их инструментов и методов), а не абстрактных рисков (как в рекламе КАСКО, где на машину падает спутник 🛰).
⏺Необходимо продумывать возможные связки
Нужно учитывать, какие уязвимости есть в системе 🚰, какими техниками они могут быть реализованы и как они комбинируются в реальных сценариях атак.
⏺Важен контекст
Одна и та же уязвимость/система может быть критичной для одной компании, но совершенно незначимой для другой.
⏺Киберразведка помогает предвидеть
Она дает информацию об актуальных угрозах и средствах злоумышленников, предсказывать возможные атаки и быстрее реагировать на инциденты.

💬 Эффективная защита — это не «залатать всё подряд», а анализировать реальные сценарии атак и закрывать те слабые места, которые злоумышленники действительно используют.

📖 InfoSec Context

🙂 9 мая
Праздник, посвящённый Дню Победы, символизирует победу над фашизмом и имеет глубокое историческое значение.

Однако этот день также можно рассматривать как праздник ИБ, так как в годы войны защита информации играла ключевую роль в обеспечении успеха военных операций. Шифрование сообщений, разведка и контрразведка — всё это было необходимо для сохранения жизней и достижения победы.

С праздником!

📖 InfoSec Context

🔐 Защита учетных данных в среде Windows.
Различные уязвимые конфигурации ПК/Сервера позволяют злоумышленнику украсть учетные данные и развить атаку.

Какие варианты харденинга возможны для снижения рисков:
1️⃣Отключить WDigest. Этот старый механизм аутентификации Windows 🌅может хранить пароль пользователя в памяти почти в открытом виде.
2️⃣Защитить LSASS (Local Security Authority Subsystem Service) — службу подсистемы локальной безопасности в операционной системе Windows. Необходимо включать RunAsPPL для защиты процесса LSASS 🤖. Это не абсолютная защита, но резко повышает сложность атаки.
3️⃣Использовать Credential Guard. Данная функция защищает от атаки типа Pass-the-Hash (PtH) и Pass-the-Ticket (PtT), при которых злоумышленники пытаются получить хэши паролей 🔐 или билеты Kerberos для дальнейшего проникновения в сеть.
4️⃣Убрать лишние привилегии у пользователей и разделить полномочия администраторов. Не должно быть администраторов с полным набором полномочий и доступов 👹.
5️⃣Настроить лимиты для RDP‑сессий. RDP используется администраторами, и настройка принудительного завершения неактивных сеансов предотвращает их сохранение на сервере. Это сокращает время доступности учетных данных администратора после завершения работы.
6️⃣Защитить механизмы аутентификации: отказ от NTLM, отключить старое RC4 шифрование в Kerberos, включение администраторов в группу Protected Users (настройка может усложнить их работу) 🤩.
7️⃣Осуществлять управление локальными и сервисными учетными записями. Необходимо применять LAPS (обеспечивает уникальный пароль локального администратора на каждом устройстве) и gMSA (пароль автоматически генерируется и регулярно ротируется средствами AD).
8️⃣Мониторинг и внедрение наложенных средств защиты 🛰.

💬 Главное в защите — не надеяться только на антивирус, а выстраивать многоуровневую и многослойную защиту. Тогда даже если злоумышленник попал внутрь, украсть что-то ценное уже намного сложнее.

📖 InfoSec Context

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

В данном случае нам на помощь может прийти ресурс https://vulners.com/ (не знаю как у вас, но мне доступен с VPN). Ресурс является большой БД 💽 уязвимостей и агрегирует данные из более чем 2️⃣0️⃣0️⃣ источников, включая популярные другие БД уязвимостей, вендорские бюллетени, эксплойты, публикации на тематических ресурсах и данные из программ bug bounty.

Ресурс имеет бесплатный 💸 план использования, который позволяет получать всю необходимую информацию при небольшом количестве запросов в день.

Одним из плюсов ресурса является представление данных в виде графа 🧛‍♂️ связанных и скоррелированных между собой, что позволяет проводить всесторонний анализ уязвимостей с учётом дополнительных метрик и доп. информации. База не заменяет сканеры уязвимостей, а неплохо дополняет их.

💬 С учётом взрывного роста атакующих ИИ-инструментов 🤖 и ускорения использования опубликованных уязвимостей не грех пользоваться дополнительным бесплатным источником.

📖 InfoSec Context

🤪 Кибербезопасность детей
Дети по-прежнему входят в группу повышенного риска среди жертв интернет-мошенников.

Почти каждый пятый ребёнок (18%) в возрасте 5–17 лет уже сталкивался с мошенническими схемами или оказывался в потенциально опасных ситуациях в цифровой среде.
Несмотря на то, что современное поколение легко осваивает гаджеты и приложения, недостаток жизненного опыта делает детей уязвимыми: их проще ввести в заблуждение, запугать или манипулировать ими в интересах злоумышленников.

Топ-3 угрозы для детей в 2026 году:
1️⃣Обман в игровых сервисах (лидирующая схема)
Мошенники предлагают выгодную покупку внутриигровой валюты, скинов или аккаунтов. Ребёнок оплачивает «товар», но ничего не получает — деньги уходят безвозвратно.
2️⃣Кражи «чужими руками» (~25% всех инцидентов)
Злоумышленники психологически давят на ребёнка: угрожают, что его родителям грозит уголовное дело (например, за «финансирование терроризма»). Испуганный ребёнок, желая защитить близких, выполняет указания: передаёт ключи, показывает места хранения ценностей или даже участвует в хищении.
3️⃣Вербовка в схемы «дропперов»
Под предлогом «простого заработка» школьников уговаривают переводить сомнительные суммы на другие карты или зарубежные кошельки. По данным ЦБ РФ, каждый пятый дроппер — несовершеннолетний.

Последствия успешной атаки могут быть серьёзнее, чем кажется:
⏺Потеря денег
⏺ Уголовная ответственность — если ребёнку уже исполнилось 14 лет и он стал соучастником мошеннической операции, закон может привлечь его к ответу.

Как защитить ребёнка?
✅ Открытый разговор — обсуждайте с детьми примеры мошенничества, учите распознавать подозрительные ситуации.
✅ Кибергигиена — простые правила: не переходить по сомнительным ссылкам, не сообщать личные данные, проверять информацию.
✅Доверие — дайте ребёнку понять: если он попал в беду, вы поможете, а не осудите.

💬 Профилактика — надёжнее любого антивируса.

📖 InfoSec Context

👨‍💻 Опять разработчики...
Уровень автоматизации, замена людей ИИ и массовые увольнения разработчиков не прошли бесследно. В последнее время стали часто появляться новости об их ошибках по опубликованию того, что не должно было публиковаться.

И вот новый факап в отношении движка Chromium: инженеры Google 📡случайно раскрыли детали критической уязвимости, которая оставалась без исправления почти четыре года. Речь идёт о баге, позволяющем запускать JavaScript-код в фоновом режиме — даже после закрытия браузера, а в отдельных случаях и после перезагрузки устройства 😳.

Предыстория
Проблему выявили ещё в конце 2022 года. Техника позволяет превратить браузер жертвы в «постоянного участника JS-ботнета». Да, JavaScript не получает прямого доступа к файловой системе, почте или операционной системе. Однако он может выполнять всё, что разрешено браузеру: проксировать трафик, участвовать в DDoS-атаках, автоматически открывать сайты, майнить криптовалюту 💰 или отслеживать активность пользователя.

Особенно тревожно ситуация выглядит в Microsoft 🌅 Edge: если раньше при эксплуатации уязвимости хотя бы появлялось всплывающее окно загрузок, то в новых версиях браузера этот индикатор исчез. В итоге вредоносный скрипт работает практически незаметно, не выдавая своего присутствия.

Самое удивительное в этой истории — временной масштаб. Ошибка оставалась без патча более 42 месяцев. Видимо, так как баг не нарушает классические границы безопасности браузера и не даёт прямого доступа к системе, то в Google могли недооценить его реальную опасность.

Текущая ситуация
Разработчики случайно пометили проблему как исправленную ещё в феврале 2026 года, однако патч так и не был выпущен. Из-за этого через 14 недель система Chromium Issue Tracker автоматически сняла ограничения и сделала отчёт об уязвимости публичным — вместе с рабочим PoC-эксплоитом. Вскоре запись снова скрыли, но то, что появилось в сети уже остается в ней 😄.

Представители Google подтвердили, что им известно о ненамеренной публикации эксплоита, и они уже работают над полноценным исправлением. Однако пока патчей нет, эксперты рекомендуют:
⏺Внимательно следить за аномалиями в меню загрузок браузера — они могут быть признаком эксплуатации;
⏺При первых признаках «тормозов» или странной активности — перезагружать браузер и устройство.

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

📖 InfoSec Context

🌇 Android теперь распознаёт фейковые звонки
Вам может позвонить «руководитель» и голос будет один в один, но это мошенник 👽. Звучит как будто сюжет триллера, но это наша новая реальность. С развитием и доступностью ИИ злоумышленники научились легко клонировать голоса, и если им удается подделать входящий номер, то не составит труда выманивать деньги у своей цели.

02.06.2026 📡 Google заявил, что для борьбы с подобным запускает защиту от поддельных звонков на телефонах Android, которая помогает распознать мошенников в реальном времени.

В чём проблема?
Мошенничество с имперсонацией (выдача себя за другое лицо, действие под именем или личностью другого человека без его разрешения) уже входит в перечень главных источников финансовых потерь (Интерпол заявляет о 400+ млрд. $ убытков в мире).

Стандартно злоумышленники комбинируют два приёма:
⏺Спуфинг номера — звонок отображается как от вашего контакта;
⏺ИИ-дипфейк голоса — голос звучит как у близкого человека или коллеги. Современные аудио-дипфейки практически неотличимы от настоящего голоса.

Что может новая защита?
На данный момент функция включена и работает по умолчанию в приложении Phone by Google следующим образом:
1️⃣Когда вам звонят, устройства отправляют друг другу зашифрованное сообщение подтверждения через технологию RCS. Это как «цифровое рукопожатие»: если звонок настоящий — устройства «узнают» друг друга.
2️⃣Если подтверждение не прошло, то телефон выдаст сообщение: «Возможно, это мошенник. Рекомендуется завершить вызов».

Как заявляется, всё происходит в реальном времени и со сквозным шифрованием. Понятно, что компетентные органы будут иметь свой корневой сертификат 😄.
Соответственно, функция работает, когда оба контакта используют приложение Phone by Google. Требуется Android 12+ и установленные приложения: Phone by Google, Contacts, Google Messages.

Функция построена на открытом стандарте RCS, поэтому другие производители и разработчики тоже смогут внедрить эту защиту. Ну а пока пользователи также могут использовать Phone by Google из Play Market.

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

📖 InfoSec Context

👨‍💻 «Меня почти взломали на собеседовании»
В прошлом году разработчик опубликовал в сети свою историю, которая должна насторожить каждого. Как он заявляет: «Я был в 30 секундах от того, чтобы запустить малварь на своём компьютере». Данная история показывает, что даже опытные специалисты не застрахованы от изощрённых атак.

Для автора все началось с сообщения от компании Symfa (реальная компания, реальный профиль, 1000+ контактов). Сообщение было в профессиональном тоне 💼 с чётким предложением на частичную занятость.
Перед интервью «рекрутер» прислал ссылку на «тестовое задание»: Bitbucket-репозиторий с тестовым проектом (React + Node.js):
⏺Чистая структура, грамотный README, документация;
⏺Даже корпоративное фото «в тему» — всё как у настоящих компаний;
⏺Дедлайн: 30 минут на ознакомление.

Так как возникла намеренная срочность, то автор решил быстро «пощупать» код — без песочницы, без Docker. Но перед запуском автор спохватился и задал простой вопрос своему AI-ассистенту (Cursor): «Проверь этот код на подозрительные активности: чтение файлов, доступ к криптокошелькам и т. п.»

И отлично сделал, так как внутри кода в массиве был закодирован скрытый URL, по адресу которого скачивался вредоносный пейлоад. При запуске кода злоумышленники получили бы доступ к: кошелькам, файлам, переменным окружения, базам данных.

💬 Данная история нам напоминает, что в цифровой среде опасность может быть где угодно. Используйте эти правила, они не будут лишними:
1️⃣ Всегда используйте песочницу. Docker, VM, WSL - любой изолированный запуск. Никогда не тестируйте чужой код на основной машине.
2️⃣ Сканируйте код перед запуском. Даже 30-секундный запрос к AI-ассистенту («Есть ли здесь подозрительные паттерны?») может спасти ваши данные.
3️⃣ Верифицируйте всё. Реальный профиль ≠ реальный человек. Реальная компания ≠ реальное предложение. Проверяйте домены, почту, контакты.
4️⃣ Доверяйте интуиции. Если вас торопят, давят дедлайном или просят «просто запустить и посмотреть» — это красный флаг 🚩
5️⃣ Обфускация — признак угрозы. Массивы байтов, eval(), new Function(), динамические импорты без явной необходимости — повод остановить и перепроверить.

📖 InfoSec Context

🇷🇺 Поздравляю вас с Днем России!
Это праздник нашей свободы и единства. Но пока вся страна видит привычные сервисы и работающие системы, именно ИТ и ИБ знает, сколько труда стоит за их стабильностью, безопасностью и доступностью.

Поэтому пусть ваш фаервол будет крепким, код — чистым, а угрозы — предотвращенными!

📖 InfoSec Context

💬 Как часто утекают ваши данные
У многих есть тот самый пароль, который они используют ВЕЗДЕ. Иногда это что-то простое, ну, вы знаете: день рождения кота, кличка собаки, "123456" или "qwerty". Иногда что-то особо сложное, но сильно постоянное. Сегодня хочу напомнить вам о ресурсе, который расскажет, насколько это была плохая идея.😁

Кто не знал, то знакомьтесь, возможно, это будущий источник ваших волнений — Have I Been Pwned

Что это и зачем оно нужно? Это самый известный в мире сервис, который покажет, утекли ли ваши личные данные и в каком сливе они засветились.
Как им пользоваться?
⏺Почта. Вбиваете свой email, и сайт выдает список всех сервисов, которые когда-либо «теряли» вашу почту. Спойлер: если вы в интернете больше пары лет, вы «засветились» минимум в десятке утечек (привет, LinkedIn, Adobe, Canva и другие).
⏺Проверка пароля. Вкладка покажет, сколько раз ваш "гениальный и очень сложный" пароль уже гулял по даркнету. (Хотя авторы и говорят, что все безопасно и поиск идет по хэшу, так что сам ваш пароль создатели не видят, но подозреваю, что такие хэши могут собираться в "радужные таблицы").
⏺Режим «Уведомить меня». Можно параноить и подписаться на уведомления (Create Alert). Как только хакеры сольют базу очередного сервиса, в котором вы зарегистрированы, вам на почту придет письмо.

💬Главная польза сервиса в том, что он лучше любых нравоучений мотивирует наконец-то перестать использовать один и тот же пароль для рабочей почты, Госуслуг и форума любителей хомяков. Делитесь в комментариях, в скольких утечках вы оказались! У кого самый «богатый» список? 👇

📖 InfoSec Context

🌇 Android: «Отображение поверх других окон»
Бывает такое, что после скачивания игры/калькулятора/фонарика (подчеркни нужное) из Google Play 📱через некоторое время с банковской карты исчезают деньги...

Магазин приложений Google Play 📱 нельзя считать полностью безопасным. Контент, конечно, проверяется, но в нем можно найти множество приложений-пустышек: «ускорители телефона»🚀, фонарики 🔦, читалки и пр. В самом приложении нет вредоносного кода, и проверка антивируса магазина проходит без проблем, но после установки приложение тихо скачивает себе нужные дополнения, которые и являются вредоносными.👽

При установке у таких «приложений» следует внимательно рассматривать запрашиваемые разрешения. Например, при установке приложение запросило разрешение «Отображение поверх других окон»? Звучит невинно и обыденно. Но именно это разрешение делает приложение опасным🤖

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

Как такое предотвратить
Для начала не качать неизвестные приложения и проверять разрешения для имеющихся 🤪. Также поищите настройку по ключевому слову «поверх», и Android 🌇 сразу выдаст вам нужное меню. Обычно данная настройка скрывается в меню: Настройки ➜ Приложения ➜ Особый/специальный доступ/права ➜ "Отображение поверх других приложений".

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

💬Друзья, кибергигиена — это как мыть руки, можно разок забить, но последствия могут быть разной степени серьезности.🧐

📖 InfoSec Context

⚓️ Эффект якоря: как первая информация меняет наше восприятие реальности

Друзья, сегодня немного полезной теории. В психологии существует феномен, который называется «эффектом якоря». Он заключается в том, что первая информация, которую мы получаем, становится точкой отсчёта для всех последующих оценок и решений. Даже если эта информация случайна или недостоверна, она продолжает влиять на наше восприятие 😵‍💫.

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

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

Сначала человеку рисуют максимально серьёзные последствия: уголовное дело, многомиллионный ущерб, потерю всех накоплений. Это и есть якорь ⚓️ — точка отсчёта, искажающая восприятие. После этого любые действия мошенников кажутся логичными и единственно верными, так как улучшают ситуацию.

Особенность эффекта заключается в том, что он действует даже на людей, которые хорошо осведомлены о манипуляциях 😝. Исследования показывают, что высокая финансовая грамотность или профессиональный опыт не устраняют его полностью.

Чтобы защититься от эффекта якоря, можно сознательно игнорировать первую цифру, угрозу или обещание, которое звучит в разговоре. Если неизвестный сообщает о катастрофических последствиях, мысленно уберите якорь и задайте себе вопрос: какие подтверждённые факты есть на данный момент?

Именно поэтому мошенники боятся пауз, перепроверки и обращения к независимым источникам. Без якоря их сценарий теряет убедительность.

💬Проверьте на себе: увидев отличную распродажу в 70% и почувствовав желание получить выгоду, остановитесь и проверьте цену в других источниках. В 99% случаев вы найдете эту «распродажную» цену и без самой распродажи. Остерегайтесь мошенников!

📖 InfoSec Context

🗺 Интерактивная карта Kubernetes для обеспечения безопасности
Недавно я узнал о проекте, который предлагает интерактивную шпаргалку по безопасности в 👩‍💻 Kubernetes. Называется kubesec-diagram и позволяет наглядно понять и визуализировать аспекты безопасности в K8s-кластере.

Чем хорош инструмент:
🟢 Интерактивность: при клике на любой компонент (например, Cluster, Deployment, Ingress, Pod и другие) появляются конкретные советы по безопасности и чек-листы.
🟢Схема наглядно демонстрирует, как компоненты взаимодействуют друг с другом, где находятся границы доверия и какие уровни защиты нужно выстраивать.
🟢Позволяет систематизировать свои знания по безопасности Kubernetes.

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

💬 Последнее обновление было всего 2 месяца назад и есть надежда на периодическую актуализацию карты.

📖 InfoSec Context

☁️ Как защитить облачную инфраструктуру: разбор главных ошибок и лучших практик
Облачные технологии - это удобно и сейчас, с ростом стоимости оборудования, становится популярно, но они сильно увеличивают поверхность атаки. Команда BI.ZONE выпустила очередной интересный гайд по защите облачных сред.
Сразу спойлер: главные риски связаны не с уязвимостями самих облачных платформ, а с ошибками конфигурации и человеческим фактором.

Ключевые направления защиты из статьи:
⏺Модель разделенной ответственности. Провайдер защищает «железо» и базовую платформу, а вот за настройку доступов, сетей и защиту данных отвечаете вы. И это касается всех моделей: IaaS, PaaS и SaaS.
⏺Ошибки в конфигурациях: Открытые бакеты (S3) и публичный доступ к ресурсам без реальной необходимости. Избыточно разрешающие сетевые правила (привет, 0.0.0.0/0)😄. Отсутствие сегментации сети и смешивание окружений (prod/dev/test). Размещение критичных сервисов в публичных подсетях.
⏺Проблемы с управлением доступами: Назначение прав администратора «на всякий случай» 🤪 и отказ от принципа наименьших привилегий. Использование root-аккаунтов в повседневных задачах. Долгоживущие токены и отсутствие многофакторной аутентификации (MFA).
⏺Отсутствие мониторинга. Без централизованного логирования вы просто не узнаете об атаке, утечке или аномальной активности, пока не станет слишком поздно.

💬 Хоть статья и рекламирует продукты BI.ZONE, но позволяет сформировать чек-лист и дает понять, что безопасность в облаке — это не разовая настройка, а непрерывный процесс. Регулярный аудит конфигураций, строгий контроль доступов, ротация ключей и обучение команды — абсолютный мастхэв для любой компании.

📖 InfoSec Context