В США завершилась многолетняя история с довольно странным и поучительным прецедентом: власти Dallas County в штате Айова согласились выплатить 600 тысяч долларов двум специалистам по безопасности, которых в 2019 году арестовали во время легального пентеста с физическим проникновением в здание суда (скорее это Red Team'инг, но спорить о терминах не готов).
А история началась с того, что пентестеры из Coalfire Labs получили письменное разрешение от судебной администрации штата на физическое тестирование уязвимостей (в том числе "взлом замков" и другие физические приемчики) в нескольких государственных зданиях, включая окружной суд. Цель – проверить, насколько здание реально защищено от несанкционированного доступа.
Во время ночного теста у одного из входов сработала сигнализация. Специалисты вошли, показали свои документы прибывшей полиции, которая подтвердила у судебных чиновников, что работа проводилась легально, но позже шериф округа настоял на их аресте по обвинению в краже и незаконном проникновении. После 20 часов в одиночной камере, оплаты залога в 100 тысяч доларов и снятия части обвинений, инцидент не закончился: пентестеры подали иск против графства и шерифа за ложный арест, злоупотребление полномочиями, клевету, нанесение морального вреда и злонамеренное преследование. Три года спустя стороны достигли урегулирования – выплаты $600000, за 5 дней до того, как должен был начаться суд.
Этот инцидент напоминает о том, насколько важно не только иметь формальное разрешение на пентест/кибериспытания, но и четко прописывать правила взаимодействия с правоохранительными органами (полиция, Росгвардия, ФСБ и т.п.) и учитывать особенности их службы. С юридической точки зрения, даже при наличии формального письма, отсутствие согласованности с местными службами может привести к неожиданным арестам и уголовным обвинениям, а это уже удар по репутации специалистов, долгие суды и возможные риски для страхования профессиональной ответственности.
Именно поэтому в России продолжается эпопея с внесением правок в законодательство по легализации деятельности "белых хакеров". Чтобы вот таких вот историй у нас не было.
#ответственность #оценказащищенности
А история началась с того, что пентестеры из Coalfire Labs получили письменное разрешение от судебной администрации штата на физическое тестирование уязвимостей (в том числе "взлом замков" и другие физические приемчики) в нескольких государственных зданиях, включая окружной суд. Цель – проверить, насколько здание реально защищено от несанкционированного доступа.
Во время ночного теста у одного из входов сработала сигнализация. Специалисты вошли, показали свои документы прибывшей полиции, которая подтвердила у судебных чиновников, что работа проводилась легально, но позже шериф округа настоял на их аресте по обвинению в краже и незаконном проникновении. После 20 часов в одиночной камере, оплаты залога в 100 тысяч доларов и снятия части обвинений, инцидент не закончился: пентестеры подали иск против графства и шерифа за ложный арест, злоупотребление полномочиями, клевету, нанесение морального вреда и злонамеренное преследование. Три года спустя стороны достигли урегулирования – выплаты $600000, за 5 дней до того, как должен был начаться суд.
Этот инцидент напоминает о том, насколько важно не только иметь формальное разрешение на пентест/кибериспытания, но и четко прописывать правила взаимодействия с правоохранительными органами (полиция, Росгвардия, ФСБ и т.п.) и учитывать особенности их службы. С юридической точки зрения, даже при наличии формального письма, отсутствие согласованности с местными службами может привести к неожиданным арестам и уголовным обвинениям, а это уже удар по репутации специалистов, долгие суды и возможные риски для страхования профессиональной ответственности.
Именно поэтому в России продолжается эпопея с внесением правок в законодательство по легализации деятельности "белых хакеров". Чтобы вот таких вот историй у нас не было.
#ответственность #оценказащищенности
🔥28❤18👍15🤔1
Верю в знаки. Вчера наткнулся в запрещенной соцсети на рассказ о том, как некий ютубер Зак Армстронг с канала LabCoatz потратил почти 1 год на изучение и воспроизведение секретной формулы Coca-Cola. Цель проекта звучала достаточно дерзко – создать химически идентичный напиток с тем же вкусом и рассказать о нем в Интернете, чтобы любой желающий мог его приготовить. Я посмотрел полученный рецепт и понял, что я никогда не буду заморачиваться, чтобы приготовить реплику Cocal-Cola (хотя я ее и так не пью).
Но дело не в этом, а в том, что сегодня подписчик прислал мне ссылку на схожую историю (интересное совпадение) про секретный рецепт формулы WD-40, которую изначально разработали для защиты корпусов ракет от коррозии. Точный состав официально не раскрывается, а сама формула, как и в случае с Coca-Cola, не запатентована специально, чтобы ее нельзя было прочитать в патентной базе. Интересная стратегия – не цифровой контроль информации, а ее отсутствие вообще (zero knowledge).
Аналогичная история и с рецептом соуса KFC "11 herbs & spices", который официально засекречен с 1940-х. Бумажная копия хранится в сейфе в Луисвилле; сотрудники видят только "свою" часть формулы, а сама смесь разделена между двумя поставщиками, чтобы никто не знал полный состав.
И таких примеров масса:
❌ Секретный рецепт ликера Шартрёз (Chartreuse), настаивающимся на 130+ травах? Рецепт известен только двум монахам ордена картезианцев и каждый знает лишь часть процесса, а сами знания передаются устно.
❌ Шотландский "национальный напиток" A.G. Barr Irn-Bru. Формула держится в секрете больше века и даже при продаже компании рецепт не раскрывается полностью новым менеджерам (хотя верится с трудом).
❌ Рецептура печенья Mrs. Fields Cookies.
Вообще. интересный способ сохранения в тайне чего-либо...
#история
Но дело не в этом, а в том, что сегодня подписчик прислал мне ссылку на схожую историю (интересное совпадение) про секретный рецепт формулы WD-40, которую изначально разработали для защиты корпусов ракет от коррозии. Точный состав официально не раскрывается, а сама формула, как и в случае с Coca-Cola, не запатентована специально, чтобы ее нельзя было прочитать в патентной базе. Интересная стратегия – не цифровой контроль информации, а ее отсутствие вообще (zero knowledge).
Аналогичная история и с рецептом соуса KFC "11 herbs & spices", который официально засекречен с 1940-х. Бумажная копия хранится в сейфе в Луисвилле; сотрудники видят только "свою" часть формулы, а сама смесь разделена между двумя поставщиками, чтобы никто не знал полный состав.
И таких примеров масса:
Вообще. интересный способ сохранения в тайне чего-либо...
#история
Please open Telegram to view this post
VIEW IN TELEGRAM
1💯36❤15🔥7🫡3👍2🥱2❤🔥1
РКН считает, что в 2025 году в России было 118 утечек ПДн и в сеть попало более 52 млн. записей. А F6 в своем отчете уверяет, что утечек было 230, а число записей составило 767 млн., что в полтора раза больше, чем в 2024-м году. А вы кому больше верите?
Anonymous Poll
4%
Роскомнадзору. Госорган не может врать!
19%
F6. Они дорожат своей репутацией!
9%
Марк Твену, который был прав!
21%
Лукацкому, кому же еще?!
7%
Мюллеру и только ему!
40%
Никому!
👏17👍5😁5😢1
Тут наткнулся на пост, в котором автор пишет, что он сам написал ИИ-агента, который ему автоматизировал работу компании, в том числе и навайбкодил систему управления знаниями, включая и систему защиты для нее. И описание всех ИБ-механизмов выложил. Ну что тут можно сказать:
➡️ Docker не изолирует от атак уровня приложений
➡️ Ни слова о том, как запускаются контейнеры (может от root'а, без seccomp/apparmor, без read-only FS и сетевых политик)
➡️ Компрометация контейнера и атакующий может забрать токен бота, сможет генерировать magic links и получит полный доступ ко всем аккаунтам.
➡️ Указывать HTTPS как "меру безопасности" – красный флаг уровня понимания ИБ. Сертификаты – это не защита, а уже из разряда must have. Но и они не защищают от кражи токенов, XSS, CSRF, утечки ссылок, подбора и т.п.
➡️ В Basic Auth пароль, передаваемый в каждом запросе, легко логируется, кешируется, перехватывается проксей и утекает через referrer. А если Telegram-авторизация добавлена поверх, то либо она дублирует пароль, что бессмысленно, либо ее можно обойти.
➡️ Магическая ссылка же может попасть в историю браузера, утечь через referrer, сохраниться в логах, быть пересланной в мессенджере, заскринена, перехвачена в рамках XSS. А кто владеет магической ссылкой, тот владеет учеткой.
➡️ 30 дней без повторной проверки – это вообще катастрофа. Хакер украл ссылку один раз и месяц имеет полный доступ ко всему.
➡️ Может быть Telegram и просто использовать в качестве системы инновационной авторизации, но это не корпоративный IdP – в нем нет контроля устройств, MDM, отзыва сессий, логирования уровня enterprise, MFA-политик. Достаточно реализовать SIM Swaping, угон Телеги через фишинг, вредонос на смартфоне, переслать ссылку и все, приплыли.
➡️ Магическая ссылка скорее всего (тут мое предположение) не связана с IP, цифровым отпечатком устройства, временем. А значит ее можно открыть где угодно и когда угодно; и переиспользовать многократно.
Сходу нагенерил 5 сценариев атаки:
6️⃣ XSS на сайте → читаем localStorage → крадем токен → получаем доступ 30 дней
2️⃣ Telegram сотрудника украли → бот → ссылка → все, пипец
3️⃣ Логи nginx → magic links → несанкционированный доступ
4️⃣ Сотрудник переслал ссылку коллеге → она стала постоянным доступом
5️⃣ Фишинг → "перешли ссылку бота" → снова несанкционированый доступ.
Видя такие идеи, понимаешь, что специалисты по ИБ еще долго будут востребованы 😊 Уж по оценке защищенности / пентестам / кибериспытаниям, так уж точно.
#архитектура #модельугроз #мессенджер #ии #оценказащищенности
Сходу нагенерил 5 сценариев атаки:
Видя такие идеи, понимаешь, что специалисты по ИБ еще долго будут востребованы 😊 Уж по оценке защищенности / пентестам / кибериспытаниям, так уж точно.
#архитектура #модельугроз #мессенджер #ии #оценказащищенности
Please open Telegram to view this post
VIEW IN TELEGRAM
❤38👍18💯7🆒1
Проводил я тут QA-сессию в 🟥 про то, как устроены MDR/SOC-as-a-Service/MSSP за рубежом. Для коллег из команды PT X, которые активно предлагают услуги MDR NG для заказчиков из разных частей света. А так как контента много, а времени было всего час с небольшим, решил все засунуть в документ. Ну и засунул... да так, что почти целая книга получилась. И не в формате маркетингового булшита, а в виде ответов на вполне конкретные и практические вопросы (FAQ), которые возникают у разных ролей внутри MDR-провайдера. Пару дней дам вылежаться документу, потом вычитаю еще раз и все, буду следующее творение готовить ✍️
#soc #тенденции
#soc #тенденции
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍21🔥9
Поляки продолжают разгонять историю про взлом 30 площадок системы энергоснабжения страны со стороны якобы русских хакеров, которые хотели оставить страну без света прямо на Новый год. Как по мне, так обвинять надо не APT Sandworm (атрибуция принадлежит ESET) или Electrum (атрибуция Dragos), тем более что полной уверенности у обоих расследователей нет, а тех, кто использовал:
📌 Fortinet FortiGate без включенной многофакторной аутентификации, смотрящие в Интернет
📌 заданные по умолчанию пароли на Fortinet FortiGate.
Именно это и позволило хакерам залезть внутрь некоторых ТЭЦ и полностью уничтожить некоторые устройства АСУ ТП.
Ты тут напрягаешься, расширяешь функционал средств защиты то поиском уязвимостей на узлах АСУ ТП, то антивирусом (это я про PT ISIM, если что), а потом оказывается, что особо одаренные инженеры просто вытащили МСЭ из упаковки, подключили к питанию, воткнули патчкорды в интерфейсы и все... решили, что "защита из коробки" выглядит именно так. А ведь европейская ENISA еще в декабре 2016-го описывала пароли, заданные по умолчанию, и отсутствие MFA как серьезные риски для АСУ ТП Старого Света. Но кто ж у нас читает рекомендации от регулятора?.. Зато виновата во всем кто? Правильно...
#асутп #инцидент
Именно это и позволило хакерам залезть внутрь некоторых ТЭЦ и полностью уничтожить некоторые устройства АСУ ТП.
Ты тут напрягаешься, расширяешь функционал средств защиты то поиском уязвимостей на узлах АСУ ТП, то антивирусом (это я про PT ISIM, если что), а потом оказывается, что особо одаренные инженеры просто вытащили МСЭ из упаковки, подключили к питанию, воткнули патчкорды в интерфейсы и все... решили, что "защита из коробки" выглядит именно так. А ведь европейская ENISA еще в декабре 2016-го описывала пароли, заданные по умолчанию, и отсутствие MFA как серьезные риски для АСУ ТП Старого Света. Но кто ж у нас читает рекомендации от регулятора?.. Зато виновата во всем кто? Правильно...
#асутп #инцидент
Please open Telegram to view this post
VIEW IN TELEGRAM
😁33👌5❤4🤝4✍1👍1🥱1
Жил-был CISO. Хороший CISO. Опытный. Видевший жизнь, инциденты и бюджеты. Верил он в безопасность. В процессы.
В методологии. И, как полагалось по времени и должности, – в отечественные средства защиты. Но не везло ему хронически. То вендор вроде свой, родной, а продукт падает на нагрузочном тестировании. То коробка сертифицирована, но чтобы она заработала, нужно три месяца шаманства. То поддержка отвечает бодро, но всегда "передадим разработке". То интегратор уверяет, что "у всех так", а у CISO потом краснеют отчеты. То все вроде работает, но ощущение – как с китайским замком: ключ есть, а спокойствия нет. В общем, не складывалось.
И вот стукнуло CISO сорок. Сидит он у себя на даче. В камине потрескивают поленья. За окном темно. В бокале – коньяк, не первый и не последний. Телефон отложен – редкая роскошь. И думает он вслух:
– Ну что ж такое… Я же не прошу невозможного. Мне не надо "лучшее в мире". Мне надо нормальное. Свое. Чтобы работало. Чтобы не стыдно было подписаться. Чтобы не ждать подвоха за каждым апдейтом.
И будто бы услышала его Судьба и думает:
– А чего это я, и правда? Хоть и с подвыпертами, и заморочками своими, но кто ж сейчас без оных. Хороший, в принципе, мужик. Многих я ему уже подбрасывала, а он все нос воротит. Но может образумился уже. Да и день рождения у него сегодня; вдруг выгорит на этот раз. Решено, помогу!..
Через пару недель на работе ему аккуратно подсунули:
– Слушай, а давай глянем вот это. Свои ребята. Без понтов и закидонов. Можно пилот сделать.
CISO скептически хмыкнул. Он таких "давай глянем" видел вагон и маленькую тележку. Но пилот поставили. И странное дело –
не упал. Заработал. Логи пошли. Интеграции не сломались. Поддержка отвечала по делу. Без героизма, но и без вранья. Документация – нормальная. Без маркетинга. Сертификаты и положительные заключения – есть. Дорожная карта – внятная.
Прошла неделя. Потом вторая. И CISO поймал себя на мысли, что… ему не тревожно. И тут он напрягся. Слишком гладко. Слишком спокойно. Слишком мало боли. Так не бывает. Начал он копать глубже. Искать подвох. Читать отзывы. Спрашивать коллег и знакомых.
– Да нормально вроде…
– Работает…
– У нас стоит, живем…
И чем больше подтверждений он находил, тем сильнее ему становилось не по себе. Потому что если это действительно работает – значит, придется брать ответственность. Придется подписывать. Включать в архитектуру. Отвечать за выбор. А вдруг потом всплывет? А вдруг через год? А вдруг он просто не докопался?
И сказал CISO:
– Нет. Рано. Давайте подождем. Сыроват еще. Надо посмотреть, как у других.
Пилот аккуратно свернули. Продукт остался в презентации. Выбор – "отложен".
А через пару месяцев CISO снова сидел на даче. Камин. Коньяк. Та же тишина. И думал:
– Ну где же нормальные отечественные решения? Почему все такое сырое?..
А Судьба ничего не ответила; только вздохнула и отвернулась...
#творчество
В методологии. И, как полагалось по времени и должности, – в отечественные средства защиты. Но не везло ему хронически. То вендор вроде свой, родной, а продукт падает на нагрузочном тестировании. То коробка сертифицирована, но чтобы она заработала, нужно три месяца шаманства. То поддержка отвечает бодро, но всегда "передадим разработке". То интегратор уверяет, что "у всех так", а у CISO потом краснеют отчеты. То все вроде работает, но ощущение – как с китайским замком: ключ есть, а спокойствия нет. В общем, не складывалось.
И вот стукнуло CISO сорок. Сидит он у себя на даче. В камине потрескивают поленья. За окном темно. В бокале – коньяк, не первый и не последний. Телефон отложен – редкая роскошь. И думает он вслух:
– Ну что ж такое… Я же не прошу невозможного. Мне не надо "лучшее в мире". Мне надо нормальное. Свое. Чтобы работало. Чтобы не стыдно было подписаться. Чтобы не ждать подвоха за каждым апдейтом.
И будто бы услышала его Судьба и думает:
– А чего это я, и правда? Хоть и с подвыпертами, и заморочками своими, но кто ж сейчас без оных. Хороший, в принципе, мужик. Многих я ему уже подбрасывала, а он все нос воротит. Но может образумился уже. Да и день рождения у него сегодня; вдруг выгорит на этот раз. Решено, помогу!..
Через пару недель на работе ему аккуратно подсунули:
– Слушай, а давай глянем вот это. Свои ребята. Без понтов и закидонов. Можно пилот сделать.
CISO скептически хмыкнул. Он таких "давай глянем" видел вагон и маленькую тележку. Но пилот поставили. И странное дело –
не упал. Заработал. Логи пошли. Интеграции не сломались. Поддержка отвечала по делу. Без героизма, но и без вранья. Документация – нормальная. Без маркетинга. Сертификаты и положительные заключения – есть. Дорожная карта – внятная.
Прошла неделя. Потом вторая. И CISO поймал себя на мысли, что… ему не тревожно. И тут он напрягся. Слишком гладко. Слишком спокойно. Слишком мало боли. Так не бывает. Начал он копать глубже. Искать подвох. Читать отзывы. Спрашивать коллег и знакомых.
– Да нормально вроде…
– Работает…
– У нас стоит, живем…
И чем больше подтверждений он находил, тем сильнее ему становилось не по себе. Потому что если это действительно работает – значит, придется брать ответственность. Придется подписывать. Включать в архитектуру. Отвечать за выбор. А вдруг потом всплывет? А вдруг через год? А вдруг он просто не докопался?
И сказал CISO:
– Нет. Рано. Давайте подождем. Сыроват еще. Надо посмотреть, как у других.
Пилот аккуратно свернули. Продукт остался в презентации. Выбор – "отложен".
А через пару месяцев CISO снова сидел на даче. Камин. Коньяк. Та же тишина. И думал:
– Ну где же нормальные отечественные решения? Почему все такое сырое?..
А Судьба ничего не ответила; только вздохнула и отвернулась...
#творчество
❤47😁44🔥18😢7👍6💔6🤔5👏1🤨1
5-АД25-119-К2.pdf
108.1 KB
Интересное дельце... Верховный суд в своем постановлении от 20 января 5-АД25-119-К2 постановил, что за инциденты на стороне подрядчиков отвечает все равно организация, этих подрядчиков привлекшая.
Фабула дела проста – 2 с лишним года назад хакеры опубликовали персональные данные сотрудников Минтруда и их родственников. Министерство подало в суд, ссылаясь на то, что это не их вина, а подрядной организации, которая и не обеспечила защиту. Но Верховный суд посчитал иначе:
➡️ персональные данные принадлежали сотрудникам Министерства
➡️ оператором ПДн было Министерство
➡️ ответственность за техническую защиту ПДн лежит на Министерстве
➡️ отвечает за ущерб Министерство
➡️ налицо факт нарушения обязанностей оператора (даже при отсутствии вреда субъектам)
➡️ по чьей именно вине произошел инцидент – вопрос вообще вторичный.
А тут еще скоро методичка к 117-му приказу выйдет, где вопросу защиты подрядчиков немало внимания уделено. Так что впору всерьез задуматься о том, как вы на практике защищаетесь от подрядчиков и как их контролируете? Я на эту тему в прошлом году выступал несколько раз (тут, тут и тут) и материалы с моих выступлений будут полезны тем, кто захочет освежить эту тему. А еще добавлю, вы не думали своих подрядчиков прогнать через кибериспытания; хотя бы по минимальной границе цены?
#ответственность #supplychain #утечка
Фабула дела проста – 2 с лишним года назад хакеры опубликовали персональные данные сотрудников Минтруда и их родственников. Министерство подало в суд, ссылаясь на то, что это не их вина, а подрядной организации, которая и не обеспечила защиту. Но Верховный суд посчитал иначе:
А тут еще скоро методичка к 117-му приказу выйдет, где вопросу защиты подрядчиков немало внимания уделено. Так что впору всерьез задуматься о том, как вы на практике защищаетесь от подрядчиков и как их контролируете? Я на эту тему в прошлом году выступал несколько раз (тут, тут и тут) и материалы с моих выступлений будут полезны тем, кто захочет освежить эту тему. А еще добавлю, вы не думали своих подрядчиков прогнать через кибериспытания; хотя бы по минимальной границе цены?
#ответственность #supplychain #утечка
Please open Telegram to view this post
VIEW IN TELEGRAM
🤔29👍16🤷♂4👀2❤1
Если продолжить тему "это не у нас инцидент, а у подрядчика", то интересное исследование провела Pentera – ее исследователи обнаружили проблему. Оказывается, учебные и демонстрационные приложения, которые компании разворачивают для обучения, тестов и демонстраций, часто остаются доступными из Интернета и слабо защищенными (удивительно). Это делает их удобным входом для злоумышленников и уже используется в реальных атаках.
Почему это важно? Потому что такие приложения не считаются частью "боевой" инфраструктуры и часто разворачиваются с минимумом контроля, а то и вовсе без него или с надеждой на хостеров, где это все разворачивается. Но они работают в той же облачной среде, где хранятся данные и сервисы бизнеса. Если их скомпрометировать – это может стать первым шагом к гораздо более серьезным последствиям.
Pentera Labs сфокусировались на традиционно уязвимых обучающих приложениях, таких как OWASP Juice Shop, Damn Vulnerable Web Application (DVWA) и Hackazon. Эти проекты изначально создаются с намеренно простыми или небезопасными компонентами для учебных целей, но:
➡️ многие из них были найдены включенными и доступными в облачных продах;
➡️ работали с настройками по умолчанию (да, это не только у FortiGate на электроподстанциях бывает);
➡️ обладали прямым выходом в Интернет без адекватной изоляции и сегментации.
Pentera разработала собственную методику и инструмент, чтобы на широкой выборке определить такие случаи просто сканируя Интернет. И оказалось, что это не просто гипотеза. Команда исследователей нашла реальные признаки активной эксплуатации уязвимых приложений – на отдельных хостах уже были развернуты:
➡️ криптомайнеры (например, XMRig), использующие чужие ресурсы для добычи криптовалюты;
➡️ вебшеллы и иные механизмы закрепления, которые дают злоумышленникам постоянный доступ.
Классическая цепочка такова:
6️⃣ Злоумышленник находит открытое учебное веб-приложение.
2️⃣ Использует известные уязвимости для удаленного выполнения кода.
3️⃣ Получает доступ к метаданным облака, откуда может извлечь учетные данные с обширными правами.
4️⃣ С этими привилегиями разворачивает майнер, шелл или переходит к другим частям инфраструктуры.
Причем такие кейсы фиксировались в том числе и на инфраструктуре, принадлежащей известным компаниям и даже вендорам безопасности, которые, казалось бы, должны быть особенно внимательны к облачной защите. А помните взломы якобы тестовых окружений некоторых отечественных ИБ-компаний? Воооот!
Так что стоит пересмотреть подходы к управлению демо-стендами и тестовыми ресурсами, учитывать их в инвентаризации, применять строжайшие политики доступа и интегрировать в процессы безопасности так же, как и остальную продуктивную инфраструктуру. А иначе придется доказывать "не виноватая я – он сам пришел". Но Верховный суд уже не поверит...
#оценказащищенности
Почему это важно? Потому что такие приложения не считаются частью "боевой" инфраструктуры и часто разворачиваются с минимумом контроля, а то и вовсе без него или с надеждой на хостеров, где это все разворачивается. Но они работают в той же облачной среде, где хранятся данные и сервисы бизнеса. Если их скомпрометировать – это может стать первым шагом к гораздо более серьезным последствиям.
Pentera Labs сфокусировались на традиционно уязвимых обучающих приложениях, таких как OWASP Juice Shop, Damn Vulnerable Web Application (DVWA) и Hackazon. Эти проекты изначально создаются с намеренно простыми или небезопасными компонентами для учебных целей, но:
Pentera разработала собственную методику и инструмент, чтобы на широкой выборке определить такие случаи просто сканируя Интернет. И оказалось, что это не просто гипотеза. Команда исследователей нашла реальные признаки активной эксплуатации уязвимых приложений – на отдельных хостах уже были развернуты:
Классическая цепочка такова:
Причем такие кейсы фиксировались в том числе и на инфраструктуре, принадлежащей известным компаниям и даже вендорам безопасности, которые, казалось бы, должны быть особенно внимательны к облачной защите. А помните взломы якобы тестовых окружений некоторых отечественных ИБ-компаний? Воооот!
Так что стоит пересмотреть подходы к управлению демо-стендами и тестовыми ресурсами, учитывать их в инвентаризации, применять строжайшие политики доступа и интегрировать в процессы безопасности так же, как и остальную продуктивную инфраструктуру. А иначе придется доказывать "не виноватая я – он сам пришел". Но Верховный суд уже не поверит...
#оценказащищенности
Please open Telegram to view this post
VIEW IN TELEGRAM
Pentera
When the Lab Door Stays Open: Exposed Training Apps Exploited for Fortune 500 Cloud Breaches - Pentera
Pentera reveals attackers exploiting exposed cloud training apps with crypto miners in Fortune 500 environments, risking full cloud compromise.
❤5👍5🔥4👌4
Тут Wiz разродилась новым фреймворком, SITF (SDLC Infrastructure Threat Framework), специально созданный для анализа, моделирования и защиты инфраструктуры, участвующей в создании, сборке и распространении программного обеспечения (SDLC). Его ключевая идея – не просто перечислить возможные риски, а визуализировать реальные пути атак, описать конкретные техники злоумышленников и связать их с рисками и защитными мерами. Он ориентирован именно на инфраструктуру SDLC (не на отдельные уязвимости в коде, а на инфраструктурные атаки на цепочку поставок), то есть на те компоненты, которые разработчики и команды используют ежедневно:
➡️ Endpoint / среда разработки (IDE)
➡️ Системы контроля версий (VCS)
➡️ CI/CD-пайплайны
➡️ Репозитории/Registry-службы
➡️ Production / среды исполнения.
SITF нужен для того, чтобы:
➡️ Понять реальные пути атаки на SDLC инфраструктуру, а не только список уязвимостей, как делает OWASP CI/CD Top10.
➡️ Сопоставить техники атак с рисками и с конкретными защитными мерами, как делает MITRE ATT&CK, но не для SDLC.
➡️ Визуально построить сценарии атак и увидеть, где именно нужно остановить злоумышленника.
➡️ Приоритизировать защиту по стадиям атак, пытаясь блокировать угрозу как можно раньше.
Основные отличия SITF от той же SLSA или SSDF:
➡️ Attack Flow Visualizer – интерактивный инструмент, в котором можно "перетащить" шаги атаки на схему и увидеть, как злоумышленник движется по инфраструктуре SDLC – от точки входа до конечного воздействия.
➡️ SITF содержит более 70 техник, типичных для инфраструктуры SDLC. Каждая техника описана с точки зрения: что происходит, какие риски это создает и какие меры защиты можно применить.
То есть главное отличие SITF в инфраструктурном взгляде, визуальных сценариях и описательном наборе "техники → риски → меры", а не просто коллекция угроз или чеклистов.
Работать с SITF можно онлайн или локально.
#framework #devsecops
SITF нужен для того, чтобы:
Основные отличия SITF от той же SLSA или SSDF:
То есть главное отличие SITF в инфраструктурном взгляде, визуальных сценариях и описательном наборе "техники → риски → меры", а не просто коллекция угроз или чеклистов.
Работать с SITF можно онлайн или локально.
#framework #devsecops
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤5🤝1
Виталик познакомился с Катей случайно. Ну ладно, не совсем случайно, – он положил прод. В пятницу вечером он решил "чуть-чуть подправить" правила корреляции в SOAR. Ничего серьезного. Просто оптимизация. Просто чтобы красивее. Через десять минут SOAR начал блокировать несуществующую атаку. Первым лег сервис авторизации, потом пара внутренних API. А следом и весь прод, аккуратно и без паники, выключился сам. Через полчаса SOC превратился в филиал ада.
В два часа ночи телефон Виталика взорвался сообщениями.
– Ты что наделал, гений?! SOAR залочил сервисные учетки и изолирует сегменты один за другим.
– Виталик, мля, срочно исправляй!
Похожий на человека, который выпил больше, чем собирался, и не то, что хотел, Виталик приехал в офис. В серверной, на фоне гудящих стоек, стояла девушка в худи, с большой кружкой явно холодного и уже неароматного кофе и крайне недовольным лицом.
– Ты прод положил, – сказала она без вступлений.
– Я… э-э… оптимизировал, – попытался оправдаться Виталик и показал изменения в правилах.
Катя молча забрала у него ноутбук, села за консоль и начала печатать. Быстро. Зло. Без комментариев.
– Что стоишь? – не оборачиваясь, сказала она. – Кофе принеси. И чтобы не мешал; просто смотри.
Виталик послушно притащил кружку с дымящимся, но не ароматным кофе из аппарата в коридоре, и стоял в сторонке, чувствуя себя учеником, который случайно поджег кабинет химии.
Минут через пятнадцать SOAR перестал "лечить" инфраструктуру. Автоблокировки снялись, сервисные учетки вернулись, сегменты снова стали доступны. Еще через несколько минут в событиях выстроилась цепочка: стало видно, что именно сработало, где автоматике дали лишнюю свободу и на каком шаге все пошло-поехало.
– Все, – сказала Катя, облегченно выдохнув, – починила.
Она повернулась и посмотрела на Виталика так, как обычно смотрят на людей, которые больше так делать не будут.
– Где ты этому научилась? – осторожно спросил он.
– Я из SOC, – пожала плечами Катя. – Ночная смена. Дочь админа старой школы.
Звучало так, будто этим можно было объяснить вообще все.
Утром, уже при свете дня, они сидели на кухне и пили нормальный кофе.
– А ты кто вообще? – спросила Катя.
– Я… архитектор безопасности. Консультант. Про стратегии, модели угроз, дорожные карты…
– Понятно, – кивнула она. – А где ты проверял изменения до вчерашнего вечера?
– В презентации, – честно ответил Виталик.
Катя усмехнулась.
– Сегодня вечером, – сказала она, – ровно в семь ты идешь со мной ужинать. В качестве извинений за ночной косяк и сломанный прод.
Позже, уже за ужином, Виталик решился:
– Слушай… а архитектуру ты тоже проектировать можешь?
– Ну да, – спокойно ответила Катя. – Просто я сразу думаю, как она будет жить: что с ней делать ночью, что ломается первым и как потом из этого выбираться.
– Тогда, может… – начал Виталик.
– Давай так, – перебила она. – Ты объясняешь, как должно быть, а я делаю так, чтобы это пережило реальность.
В ту ночь они больше про работу не говорили...
А Виталик еще много лет благодарил тот самый "безобидный" пятничный апдейт. И только вздыхал, когда у него аккуратно забирали клавиатуру и говорили:
– Давай ты лучше расскажешь, как должно быть, а я буду делать, чтобы это работало.
И SOC снова засыпал.
#творчество
В два часа ночи телефон Виталика взорвался сообщениями.
– Ты что наделал, гений?! SOAR залочил сервисные учетки и изолирует сегменты один за другим.
– Виталик, мля, срочно исправляй!
Похожий на человека, который выпил больше, чем собирался, и не то, что хотел, Виталик приехал в офис. В серверной, на фоне гудящих стоек, стояла девушка в худи, с большой кружкой явно холодного и уже неароматного кофе и крайне недовольным лицом.
– Ты прод положил, – сказала она без вступлений.
– Я… э-э… оптимизировал, – попытался оправдаться Виталик и показал изменения в правилах.
Катя молча забрала у него ноутбук, села за консоль и начала печатать. Быстро. Зло. Без комментариев.
– Что стоишь? – не оборачиваясь, сказала она. – Кофе принеси. И чтобы не мешал; просто смотри.
Виталик послушно притащил кружку с дымящимся, но не ароматным кофе из аппарата в коридоре, и стоял в сторонке, чувствуя себя учеником, который случайно поджег кабинет химии.
Минут через пятнадцать SOAR перестал "лечить" инфраструктуру. Автоблокировки снялись, сервисные учетки вернулись, сегменты снова стали доступны. Еще через несколько минут в событиях выстроилась цепочка: стало видно, что именно сработало, где автоматике дали лишнюю свободу и на каком шаге все пошло-поехало.
– Все, – сказала Катя, облегченно выдохнув, – починила.
Она повернулась и посмотрела на Виталика так, как обычно смотрят на людей, которые больше так делать не будут.
– Где ты этому научилась? – осторожно спросил он.
– Я из SOC, – пожала плечами Катя. – Ночная смена. Дочь админа старой школы.
Звучало так, будто этим можно было объяснить вообще все.
Утром, уже при свете дня, они сидели на кухне и пили нормальный кофе.
– А ты кто вообще? – спросила Катя.
– Я… архитектор безопасности. Консультант. Про стратегии, модели угроз, дорожные карты…
– Понятно, – кивнула она. – А где ты проверял изменения до вчерашнего вечера?
– В презентации, – честно ответил Виталик.
Катя усмехнулась.
– Сегодня вечером, – сказала она, – ровно в семь ты идешь со мной ужинать. В качестве извинений за ночной косяк и сломанный прод.
Позже, уже за ужином, Виталик решился:
– Слушай… а архитектуру ты тоже проектировать можешь?
– Ну да, – спокойно ответила Катя. – Просто я сразу думаю, как она будет жить: что с ней делать ночью, что ломается первым и как потом из этого выбираться.
– Тогда, может… – начал Виталик.
– Давай так, – перебила она. – Ты объясняешь, как должно быть, а я делаю так, чтобы это пережило реальность.
В ту ночь они больше про работу не говорили...
А Виталик еще много лет благодарил тот самый "безобидный" пятничный апдейт. И только вздыхал, когда у него аккуратно забирали клавиатуру и говорили:
– Давай ты лучше расскажешь, как должно быть, а я буду делать, чтобы это работало.
И SOC снова засыпал.
#творчество
12❤55🔥31😁7❤🔥5👍5😴5
Рынок киберстрахования за последние годы вырос настолько, что перестал быть нишевой историей про "компенсацию инцидентов". Он стал похож на классическое страхование природных катастроф – ураганов, землетрясений, наводнений. С той же проблемой: редкие, но очень дорогие события, которые могут снести сразу половину портфеля. И вот тут начинается самое интересное. Если в физическом мире все понятно – разнес риски по географии, и уже легче дышится, то в кибербез этот трюк почти не работает. Интернет не знает границ, облака одни и те же, операционки одни и те же, уязвимости одни и те же. Один крупный сбой – и страдают все одновременно.
Именно это и разбирает CyberCube в своем очередном исследовании. Первый логичный вопрос, который они задают: можно ли вообще диверсифицировать киберриски? Оказывается – можно. Но не так, как привыкли страховщики. Размазать портфель по странам – звучит разумно, но на практике эффект почти нулевой. Географическая диверсификация дает максимум 11% выигрыша, а для "хвостовых" сценариев (событие раз в 200 лет) – всего 2%. А все потому, что атаки и технологии глобальные. Один и тот же облачный провайдер обслуживает клиентов по всему миру. Один и тот же баг в Windows – сразу везде. Границы государств здесь просто не участвуют.
Если смешивать малый бизнес, средний и крупный – уже появляется эффект: до 17% снижения риска. Если распределять портфель по отраслям – ситуация становится еще лучше – до 27%. Логика понятна – разные индустрии используют разный технологический стек, по-разному интересны злоумышленникам и по-разному восстанавливаются. А если комбинировать географию + размер + отрасли, получается уже совсем интересно – до 38% снижения и 33% даже в хвосте, то есть для событий, происходящих один раз в 200 лет. Это уже деньги, которые можно увидеть в капитальных требованиях и в цене перестрахования.
Главная проблема ИТ-рынка – технологическая концентрация. Цифры из отчета говорят сами за себя:
➡️ AWS – ~31% мирового рынка облаков
➡️ Windows – ~72% рынка десктопных ОС
➡️ три крупнейших американских облака – 75% рынка
➡️ больше половины облачных регионов, которыми пользуются компании по всему миру, физически находятся в США.
То есть вся «диверсификация» легко ломается одной аварией или одной масштабной атакой на крупного провайдера. Фактически это цифровые "гидроэлектростанции": упал один – темно у половины страны. Тем не менее, даже тут есть пространство для маневра. Если в портфеле не все сидят на одном облаке, а, например, часть на AWS, часть на Azure, можно получить до 38–42% снижения катастрофических потерь (интересно, для ВК/Яндекса будет работать тот же принцип?). И вот это уже действительно чувствительно.
#страхование
Именно это и разбирает CyberCube в своем очередном исследовании. Первый логичный вопрос, который они задают: можно ли вообще диверсифицировать киберриски? Оказывается – можно. Но не так, как привыкли страховщики. Размазать портфель по странам – звучит разумно, но на практике эффект почти нулевой. Географическая диверсификация дает максимум 11% выигрыша, а для "хвостовых" сценариев (событие раз в 200 лет) – всего 2%. А все потому, что атаки и технологии глобальные. Один и тот же облачный провайдер обслуживает клиентов по всему миру. Один и тот же баг в Windows – сразу везде. Границы государств здесь просто не участвуют.
Если смешивать малый бизнес, средний и крупный – уже появляется эффект: до 17% снижения риска. Если распределять портфель по отраслям – ситуация становится еще лучше – до 27%. Логика понятна – разные индустрии используют разный технологический стек, по-разному интересны злоумышленникам и по-разному восстанавливаются. А если комбинировать географию + размер + отрасли, получается уже совсем интересно – до 38% снижения и 33% даже в хвосте, то есть для событий, происходящих один раз в 200 лет. Это уже деньги, которые можно увидеть в капитальных требованиях и в цене перестрахования.
Главная проблема ИТ-рынка – технологическая концентрация. Цифры из отчета говорят сами за себя:
То есть вся «диверсификация» легко ломается одной аварией или одной масштабной атакой на крупного провайдера. Фактически это цифровые "гидроэлектростанции": упал один – темно у половины страны. Тем не менее, даже тут есть пространство для маневра. Если в портфеле не все сидят на одном облаке, а, например, часть на AWS, часть на Azure, можно получить до 38–42% снижения катастрофических потерь (интересно, для ВК/Яндекса будет работать тот же принцип?). И вот это уже действительно чувствительно.
#страхование
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍13❤4🤔4🤝1
Самая сильная часть исследования CyberCube ☝️ – про нейтрализацию рисков/угроз. Мы привыкли думать, что патчи, сегментация и бэкапы уменьшают "операционные" инциденты, но на катастрофы почти не влияют. Ну еще бы, такие мелочи и против отраслевых или даже страновых недопустимых событий. Оказалось – наоборот.
CyberCube смоделировал портфель компаний с плохой гигиеной (Basic) и с продвинутой (Advanced). И сравнил хвостовые убытки. Результат – при переходе с базового на продвинутый уровень происходит снижение хвостового риска:
➡️ по всем сценариям – минус 57%
➡️ для массовых простоев эффект слабее, но резервные копии все равно дают 22% снижения
➡️ для массовых атак ransomware – до 80%
Восемьдесят, мать его, процентов! То есть речь не про косметику. Базовые, даже я бы сказал, банальные меры ИБ:
➡️ своевременные патчи
➡️ сегментация сети
➡️ нормальные резервные копии
реально уменьшают вероятность и масштаб киберкатастроф, а не только "мелкие" инциденты. Патчи, сегментация и бэкапы – это уже не просто best practice, а фактор устойчивости финансовых рынков. Никакого zero trust, ИИ и прочего футуризма. Просто дисциплина и цифровая гигиена.
Что это значит на практике? Для страховщиков:
➡️ диверсификация портфеля – реальный финансовый рычаг
➡️ сбор данных о состоянии ИБ клиентов становится экономически важным, а не просто формальностью. А значит анкеты "для галочки" уже не подойдут – нужны реальные проверки, пентесты, кибериспытания...
Для CISO это означает, что:
➡️ появляется редкий шанс говорить с бизнесом на языке денег
➡️ вместо "нам нужны патчи" → говорим "минус 50–80% потенциальных катастрофических потерь"
➡️ зависимость от одного облака или одного стека – уже не ИТ-решение, а финансовый риск; особенно для крупных компаний.
CyberCube резюмирует – киберстрахование окончательно входит в эпоху катастроф. География почти не спасает. Технологические монополии усиливают системный риск. Но простая кибергигиена способна сократить хвостовые потери наполовину и больше. То есть иногда самый эффективная защита – это не новый продукт, а просто вовремя поставленный патч🤔
ЗЫ. И, о, сюрприз, оказывается, что ИБ – это не про навороченные решения в первую очередь, а про банальную работу ИТ.
#страхование #bestpractice #недопустимое
CyberCube смоделировал портфель компаний с плохой гигиеной (Basic) и с продвинутой (Advanced). И сравнил хвостовые убытки. Результат – при переходе с базового на продвинутый уровень происходит снижение хвостового риска:
Восемьдесят, мать его, процентов! То есть речь не про косметику. Базовые, даже я бы сказал, банальные меры ИБ:
реально уменьшают вероятность и масштаб киберкатастроф, а не только "мелкие" инциденты. Патчи, сегментация и бэкапы – это уже не просто best practice, а фактор устойчивости финансовых рынков. Никакого zero trust, ИИ и прочего футуризма. Просто дисциплина и цифровая гигиена.
Что это значит на практике? Для страховщиков:
Для CISO это означает, что:
CyberCube резюмирует – киберстрахование окончательно входит в эпоху катастроф. География почти не спасает. Технологические монополии усиливают системный риск. Но простая кибергигиена способна сократить хвостовые потери наполовину и больше. То есть иногда самый эффективная защита – это не новый продукт, а просто вовремя поставленный патч
ЗЫ. И, о, сюрприз, оказывается, что ИБ – это не про навороченные решения в первую очередь, а про банальную работу ИТ.
#страхование #bestpractice #недопустимое
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤4⚡3👌1