Информационная безопасность *

Юрий Подгорбунский, Security Vision

Введение

Требования к безопасности критической информационной инфраструктуры (далее – КИИ) установлены Федеральным законом от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (далее – Федеральный закон).

Цель Федерального закона заключается в предъявлении требований безопасности для обеспечения устойчивого функционирования КИИ при проведении в отношении ее компьютерных атак.

Основные понятия

Компьютерная атака представляет собой целенаправленное воздействие программных и (или) программно-аппаратных средств на объекты КИИ, сети электросвязи, используемые для организации взаимодействия таких объектов, в целях нарушения и (или) прекращения их функционирования и (или) создания угрозы безопасности обрабатываемой такими объектами информации.

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

Остальные основные понятия в статье будут рассматриваться ниже последовательно. 

Что же такое КИИ?

В целом КИИ – это объекты КИИ, а также сети электросвязи (сети операторов связи), используемые для взаимодействия таких объектов.

А сами объекты КИИ — это следующие системы и сети:

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

Герой этой статьи, Sony BMG, испытывала к пиратам такую личную неприязнь, что кушать не могла решила встроить защиту от пиратства на свои диски, причем защита была настолько капитальной, что формально являлась чистым руткитом, безальтернативно устанавливаемым всем PC-пользователям. Надо ли говорить, что как только о рутките стало известно, им воспользовались все, кто мог, кроме самой Sony.

Иногда доступ во внутреннюю сеть — это не начало атаки, а тупик. Именно в такой ситуации я оказался в самом начале.

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

Кратко напомню отправную точку: в ходе тестирования внешней инфраструктуры заказчика нам удалось получить доступ во внутреннюю сеть через туннелирование. Чтобы не дублировать материал, отмечу лишь, что схема была реализована по подходу, описанному у моих друзей из компании «Deiteriy Lab» в статье - https://habr.com/ru/companies/deiteriylab/articles/920064/. Способ отличный и полностью рабочий, советую взять на вооружение. Для общего представления приведу схему подключения, которую мы использовали (так же взята из статьи).

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

Black-box подразумевает, что у пентестера нет никакой внутренней информации: ни списков IP, ни учётных данных, ни описания архитектуры. Только доменное имя - и вперёд. Звучит как ограничение, но на практике это зачастую преимущество: вы смотрите на инфраструктуру глазами реального злоумышленника.

Целью данного пентеста является проверка возможности компрометации внутренней инфраструктуры через веб-приложения.

Почти каждый человек в СНГ пользуется телеграмом, но не каждый задумывается о том, на каких костылях держится его любимая платформа. Всё начинается с «печатает...» в избранном, а заканчивается тем, что форумы — лишь иллюзия интерфейса.

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

Компаниям, выходящим на экспортные рынки, часто сложно найти менеджеров по продажам, владеющих иностранными языками. Одно из решений — привлекать иностранцев. Например, в странах Африки много молодых людей, которые, имея два родных языка, прекрасно владеют ещё и английским.

Год назад я «с нуля» собирал отдел международных продаж. Требования к кандидатам были простыми: свободный английский, стрессоустойчивость, работоспособность и позитивный настрой. Отбор сделали многоэтапным.

На вакансию откликнулась кандидат мечты. Она успешно прошла первый этап — тест на владение устным английским с филологом. Лёгкий акцент на собеседовании меня не смутил: для рутинной работы с потенциальными клиентами это не критично. Море энтузиазма, обаяния и непосредственности — именно то, что нужно.

Уже потом вспомнились странности: слегка «плывущая» картинка на онлайн-встрече и необычный, размытый фон.

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

Во время теста мы не придали значения странным техническим проблемам: обрывы связи, зависания, проблемы со звуком.

На финальном этапе «не самый гадкий утёнок» внезапно превратился в настоящего американского белоголового орлана. Когда обсуждали условия работы и зарплату, её английский звучал практически как родной. Лексика, грамматика, подача, скорость речи — уровень как минимум телеведущего новостного блока CNN.

Хабр, привет! На связи Алина Байрамова, аналитик-исследователь угроз кибербезопасности R-Vision.

В этой статье я разберу уязвимость нулевого дня в TrueConf Server (CVE-2026-3502), связанную с механизмом обновлений, и то, как она может быть использована для компрометации изолированных инфраструктур через доверенный канал распространения ПО.

Привет, Хабр!

Я Ирина Слонкина из отдела безопасности распределенных систем, Positive Technologies. Вместе с коллегами исследую безопасность смарт-контрактов и блокчейн-приложений. Конечно, всегда интересно вникнуть вглубь каждой технологии, вышедшей на рынок. В этой статье я расскажу про криптографический протокол PLONK, один из самых интересных протоколов в блокчейн-индустрии.

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

Статья будет без ИИ мусора и прочего пустословия. Обсудим способы выживания на операционной системе Android в тяжелых условиях.

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

Медицинскую клинику у приличных людей сегодня выбирают не по рейтингу, не по врачам и не по локации. А по тому, в чьих руках окажется анамнез после лечения. Попадали ли когда-нибудь анализы её пациентов в открытый доступ? Если нет — можно рискнуть. Гарантий, впрочем, никаких.

Вот уже почти полгода, после ухода со службы в ФНС, я помогаю разбираться в реальных механизмах налогового контроля. Для связи с читателями я сделал телеграм канал «Налоговый Инсайдер», в котором отвечаю на вопросы и развенчиваю мифы, которые любят тиражировать различные псевдоэксперты и СМИ.

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

Сам комментарий звучит так:

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

На связи Иван Глинкин, руководитель группы аппаратных исследований из команды Бастиона. Сегодня займемся реверс-инжинирингом штатного ключа автомобильной сигнализации (key fob) китайского JAC JS4, известного в России как Москвич 3. Этот китаец с русским именем за несколько лет уверенно прописался на наших дорогах, но в инфополе до сих пор нет информации о его тестировании на стойкость к взлому. 

Итак, вызов принят! Мы проведем детальное исследование компонентной базы брелока, изучим его внутренности, просканируем эфир с помощью SDR, постараемся выявить плавающий код (hopping/rolling code) и наметим несколько векторов атаки.

Субботний день 24 октября 2020 года выдался дождливым, ветреным и довольно прохладным — впрочем, такую погоду можно назвать типичной для осеннего Хельсинки. Люди прятались от промозглой сырости в уютных кафе и ресторанах, пили горячий чай и глинтвейн, стараясь отдохнуть за выходные от насущных дел. Внезапно их мобильные телефоны — практически одновременно, с разницей в секунды — начали оживать, сигнализируя о пришедших по электронной почте сообщениях. Студенты, политики, учителя, врачи, водители, и даже безработные вглядывались в экраны с тревогой и ужасом. Эти люди никогда раньше не встречались и никогда не увидятся в реальности. У них не было ничего общего — кроме одного: несколько лет назад каждый из них зашел в кабинет психотерапевта известной сети центров психологической помощи Vastaamo и закрыл за собой дверь. То, что они говорили за той дверью, должно было навсегда остаться там же. Но теперь неизвестный хакер утверждал: он располагает всеми записями этих сессий, включая имена, даты и самое главное — подробные признания пациентов. Двести евро в биткоинах — и похищенная информация не будет опубликована в общем доступе. На раздумья — двадцать четыре часа. Время пошло.

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

AI-агент на OpenClaw слил $441 000 за один твит. Разбор шести катастроф и архитектуры, которая меня пока спасает

Один твит про «лечение столбняка для дяди» — и автономный агент Lobstar Wilde переводит незнакомцу 5% всего предложения криптопроекта. Это не сценарий киберпанк-триллера, а реальность февраля 2026 года.

Если вы используете OpenClaw или любой другой фреймворк для self-hosted агентов, эта история касается вас напрямую. Почему одни инстансы раздают бюджет первым встречным, а другие остаются в безопасности?

Внутри статьи:

Анатомия 6 крупнейших провалов: от «Тахо за $1» в Chevrolet до разбитых витрин в Чикаго и краха GPT-5 на криптобирже.

Где у агента дыры: разбираем уязвимости на уровнях Input, Reasoning, Tools и Memory.

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

У меня на сервере сейчас крутится OpenClaw-агент. Он может читать, писать, перезагружать контейнеры, лезть в базы, выполнять shell-команды. У него куча прав. Но у него нет доступа к платёжным API. У него нет ключей от криптокошельков. У него нет возможности инициировать что-то, чего нельзя откатить одним git reset или docker restart.

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

Месяц искал VPN который не палит Россию перед ИИ. Нашёл - 24 часа бесплатно, попробовал. Написал в поддержку прямо во время установки. Три минуты — живой человек, сразу инструкция. Сработало. А потом понеслась …

Недавно все мы услышали громкое заявление Anthropic «наша модель Mythos очень опасна из-за своих хакерских способностей». Когда (пока) к модели нет массового доступа, человечеству сложно проверить, как все обстоит на самом деле, а хайп разгонял ряд событий:

• в США и Великобритании прошли экстренные совещания в банковском секторе о том, как действовать в новых реалиях;

• OpenAI представили свой «вариант для кибербезопасности» GPT‑5.4‑Cyber;

• а сервис cal.com заявил, что из опенсорсного станет закрытым, потому что обеспечивать безопасность открытого кода теперь слишком сложно.

Но. Появились первые сторонние тексты с анализом способностей Mythos. Это позволяет получить хотя бы частичное, не по заявлениям Anthropic, понимание ситуации. Поэтому мы собрали их в один хабрапост, чтобы разобраться: что в Mythos миф, а что реальность, и насколько стоит обращать внимание на происходящие?

Примечание: это перевод свежего поста из блога Mozilla о том, что дало использование ИИ для поиска уязвимостей в Firefox. Ранее на схожие темы уже высказывались мейнтейнеры Linux, но пост Mozilla интересен общим оптимистичным прогнозом для индустрии.

С февраля команда Firefox непрерывно работает с передовыми ИИ-моделями, чтобы выявлять и устранять скрытые уязвимости в браузере. Ранее мы уже писали о нашем сотрудничестве с Anthropic по сканированию Firefox с помощью Opus 4.6, благодаря чему были исправлены 22 критические ошибки в Firefox 148.

Далее в рамках сотрудничества с Anthropic мы смогли применить к Firefox раннюю версию Claude Mythos Preview. И выпущенная на этой неделе версия Firefox 150 включает исправления 271 уязвимости, которые были выявлены в ходе этого тестового использования.

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

За последние десятилетия мы как-то все привыкли, что живем в уютной айтишечке – собственном, закрытом мире, практически лишенном недостатков. И в этом мире были кофе по утрами, смузи в обед и неограниченные поездки на такси, часто оплачиваемые напрямую работодателем. И проблем как будто вообще не существовало. Мы выбирали себе новых работодателей, меняя их как перчатки, и за каждую смену места работу гарантированно получали надбавку 10-30% к заплате.

Но, оглянитесь, времена меняются. А в каких-то странах и в каких-то it-направлениях поменялись невозвратно.

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

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

Так вот, один из законов развития такого мира заключается в том, что монополии и государство неизбежно сближаются, сращиваются, сливаются в страстном поцелуе взасос. И это обоюдное влечение, обусловленное объективными экономическими интересами.

В нашей сегодняшней it-индустрии эти процессы происходят прямо сейчас. Нет, они были и раньше, но в последние пару лет и даже месяцев всё это закрутилось с новой, невиданной ранее скоростью. И наши сегодняшние лидеры отрасли - Яндекс, Т-Банк, Озон и другие – наперегонки спешат слиться с государством, а государство спешит слиться с ними. И так – далеко не только в РФ.

От криптоанализа к AI-forensics

Мы привыкли считать LLM «чёрным ящиком»: дал промпт — получил ответ. Максимум — подкрутил fine-tuning или LoRA и надеешься, что стало лучше. Мы пошли в другую сторону. В предыдущей статье я показал, что подписи Schnorr / MuSig2 можно разобрать до уровня строгих affine-инвариантов и работать с ними как с математической системой, а не как с магией. В этой работе мы сделали следующий шаг: перенесли ту же exact-методологию внутрь нейросети.

Что мы сделали? Мы взяли локальный MLX-дистрибутив:

gpt-oss-20b-TurboQuant-MLX-8bit

и не стали его «обучать заново». Вместо этого: вскрыли .safetensors на уровне квантованных кодов; построили детерминированный calibration cache; начали снимать реальные BF16-активации с конкретных слоёв; свели задачу к локальной integer-оптимизации квантованных весов; реализовали безопасный patch прямо в модель; и добавили smoke-check, который проверяет: совпадает ли наша математика с реальным runtime MLX.

Что получилось

Мы впервые получили pipeline, в котором: квантованный слой наблюдаем; его поведение измеримо; его можно локально корректировать; и самое важное - можно проверить, не обманывает ли нас сама среда исполнения. Например: для router.weight мы получили почти полный перенос улучшения на holdout; для q_proj система честно доказала: без внешнего эталона patch не имеет смысла. И это, возможно, даже важнее.