Компания «Доктор Веб» выпустила практические рекомендации по усилению безопасности ИТ-инфраструктуры для компаний и сотрудников по ИБ. Документ основан на многолетнем опыте работы службы технической поддержки «Доктор Веб» и департамента по расшифровке файлов,
Стартовала работа над новым бумажным спецвыпуском журнала «Хакер». На этот раз в коллекционный сборник войдут лучшие статьи, опубликованные в 2025 году: от разбора сетевых протоколов до хакерских применений LLM.
После выпуска трёх бумажных сборников с архивными статьями за 2015–2021 годы в «Хакере» решили попробовать новый формат: журнал, в котором будут собраны лучшие статьи за год. В новый номер войдут более 20 топовых текстов, публиковавшихся на страницах «Хакера» в 2025 году. Каждая статья по традиции будет сопровождаться уникальными комментариями от авторов и редакторов, которые позволят заглянуть за кулисы работы журнала. 240 страниц на плотной бумаге — вдвое толще старых номеров «Хакера» образца 2015 года.
Лучшие статьи за год, подшивка всего самого интересного:
Автоматизация хакерских тасков при помощи LLM;
Полный гайд по разведке перед пентестом;
Разбор популярных сетевых протоколов с примерами;
Туториал по опенсорсному отладчику radare2;
Новые способы обфускации малвари в Windows;
Хакерские трюки и софт для Android;
И многое другое.
Интеграция PVS-Studio с Hexway
Компания PVS-Studio и платформа Hexway заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
Hexway VamPy — это решение, агрегирующее данные о безопасности из разных источников для работы с уязвимостями.
В Hexway стало возможным загрузить результаты анализа PVS-Studio в виде отчёта и работать с конкретными ошибками так же, как это позволяют другие инструменты. Загрузка возможна двумя способами: через пользовательский интерфейс или командную строку с использованием CLI-инструментов.
Подробнее о том, как загрузить результаты анализа PVS-Studio в Hexway VamPy можно прочитать в соответствующем разделе нашей документации.
Как обойти защиту JWT?
В этом видео инженер по безопасности приложений Swordfish Security Денис Данилов разбирает уязвимость стандарта передачи данных JSON Web Token (JWT).
Суть уязвимости
JWT состоит из трех частей:
Header — заголовок, где указывается алгоритм подписи (например, HS256),
Payload — полезная нагрузка (данные пользователя, роли и т. д.),
Signature — подпись, которая формируется с помощью секретного ключа.
Проблема возникает, если сервер не проверяет, какой алгоритм указан в заголовке. Если там стоит alg: "None", библиотека может интерпретировать это буквально — и не проверять подпись вовсе.
В результате злоумышленник может:
извлечь JWT токен (например, из cookies),
заменить полезную нагрузку (например, указать "role": "admin"),
подставить alg: "None" в заголовке,
отправить подделанный токен на сервер и получить доступ к чужому аккаунту.
Как научиться находить такие уязвимости?
Такой тип ошибки — не уникален для JWT. Это общий паттерн: разработчик полагается на библиотеку, не разбираясь в деталях. В продакшене такие недочёты дорого обходятся — и бизнесу, и карьере инженера.
Swordfish Security мы регулярно сталкиваемся с подобными уязвимостями в реальных проектах. Опыт показывает: даже базовое понимание архитектуры протоколов и моделей угроз помогает разработчикам предотвращать критичные ошибки ещё на этапе проектирования. Этот кейс, кстати, — часть одного из модулей курса по DevSecOps нашей академии, где мы разбираем типовые уязвимости и подходы к их предотвращению.
Благодаря найденной уязвимости я зарегистрировал CVE-2024-45244, попал на спикер-пати OffZone 2024 (как докладчик) и в топ-10 "Pentest Award 2025" (номинация Out Of Scope). А ведь этого всего могло бы и не быть, если бы я не продолжил настаивать на своём (невзирая на мнение моего тогдашнего тимлида). Уязвимость обнаружил несколько лет назад в процессе исследования безопасности коммерческого смарт-контракта. Сообщил тимлиду (отдел занимался безопасностью блокчейна) во всех подробностях, даже макет с результатами показал и описал. Но, тимлид проигнорировал мою находку. Он до этой работы не имел практического опыта в безопасности (был разработчиком). Врезалось в память, как он называл себя "самым компетентным по блокчейнам в отделе". После моего отказа на предложение добровольно стать "козлом отпущения", у него появились претензии к моей работе. Мол, это я ничего не смыслю в безопасности блокчейнов. В какой-то момент он даже позвал HR бизнес-партнёра на 3-х сторонний диалог (видимо, показать, что он не одинок во мнении насчёт моей компетенции). HR весь наш диалог молчала, "считая ворон". А в конце выдала гениальное: я не поспеваю за темпом компании в безопасности. И, вообще-то, очень плохо, что я не внимаю мнению руководителя - тимлидом абы кого не ставят (видимо, кейс с президентом Ельциным молодое поколение HR-ов и не знает). Учитывая, что у компании одной из целей был поиск CVE в блокчейнах, и на текущий момент в публичной плоскости у них так ни одной CVE в этой области не появилось - большой вопрос: кто за кем не поспел.
Сегодня, прочитав статью "Когда руководитель не руководитель. Синдром «Самого умного» я вспомнил не только разработчиков блокчейна, пафосно уверявших меня, что проблемы нет, они-то лучше меня знают свой продукт. А фикс - только чтоб меня успокоить (подробнее в статье "Как я зарегистрировал CVE и разозлил вендора"). Я также вспомнил своего бывшего тимлида. И ведь такие люди - не редкость. На одной из лекций психологу задали вопрос почему среди руководителей часто нарциссы? Ответ: обычный человек 10 раз подумает стоит ли идти в руководители. У нарциссов же это желанная цель: уже самой своей должностью показывать подчинённым кто в доме хозяин. Надо сказать, что такие люди любят публичный вынос "сора из избы". Пример с этим тимлидом - на картинке.
Что делать когда сталкиваешься с такими людьми? Это дело каждого. Но, лично я солидарен с психологом: не пытаться что-то им доказать, не вестись на провокации, и постараться не пересекаться в жизни (если нужно - сменить работу). Ну, и CVE, OFFZONE, Pentest award - те вещи, которые вряд ли бы появились, если бы не сменил работодателя.
Проект Zero Day Initiative (ZDI) сообщил о проведении соревнований Pwn2Own Ireland 2025, которые состоятся в середине октября 2025 года в Ирландии. Участникам предложено продемонстрировать эксплоиты для ранее неизвестных уязвимостей (0-day) в смартфонах, мессенджерах, беспроводных точках доступа, устройствах для умного дома, принтерах, сетевых хранилищах, системах видеонаблюдения и устройствах виртуальной /дополненной реальности. Атака должна быть проведена на самые свежие программы и операционные системы со всеми доступными обновлениями и в конфигурации по умолчанию.
Мероприятие примечательно готовностью выплатить миллион долларов за выявление в мессенджере WhatsApp ошибки, позволяющей удалённо выполнить код без действия пользователя (0-click). За удалённо эксплуатируемую уязвимость в WhatsApp, требующую действий пользователя (1-click), премия составляет 500 тысяч долларов, за уязвимость, приводящую к захвату учётной записи - $150 тысяч, а за получение удалённого доступа к данным пользователя, микрофону или камере - $130 тысяч.
В категории "мобильные телефоны" за удалённую эксплуатацию уязвимости в смартфонах Google Pixel 9 и Apple iPhone 16 назначена премия 300 тысяч долларов. При этом введена новая категория - взлом устройства при подключении по USB c размером премии $75 тысяч. За удалённый взлом 3D-шлема Meta Quest 3/3S и умных очков Meta Ray-Ban назначено вознаграждение в $150 тысяч. Максимальный размер премии за взлом устройств умного дома и сетевых хранилищ составляет $50 тысяч, систем видеонаблюдения - $30 тысяч, а принтеров - $20 тысяч.
Обеспечивают ли конфиденциальную связь современные сервисы? В популярных мессенджерах есть функции для этого, используется сквозное шифрование, можно даже проверить исходный код. Это хорошо, но есть риск того, что при форс-мажорных обстоятельствах хозяева сервиса выпустят обновление с бэкдором, позволяющим обходить шифрование и проводить атаку посередине на канал связи интересующих пользователей.
Конфиденциальность может быть гарантирована только в случае, когда она обеспечена самими собеседниками. Как можно реализовать это? Использовать шифрование данных своими ключами. При этом возникает проблема передачи секретного ключа собеседнику. Она надёжно решается при личной встрече. Но что делать, когда такой возможности нет или собеседников по секретным вопросам много? Собеседникам можно действовать по следующему алгоритму:
Зарегистрироваться по своему номеру телефона в двух-трёх мессенджерах из разных юрисдикций, в которых есть функции сквозного шифрования. Например, в Телеграм, Signal и Wire.
Включить в мессенджерах сквозное шифрование и выключить резервное копирование сообщений.
Одному собеседнику сгенерировать и выслать второму составные части ключа шифрования в разных мессенджерах. Например, три части по 85, 85 и 86 (суммарно 256) бит.
После приема частей ключа получателю объединить их и хранить в надёжном месте.
Обоим собеседникам удалить отправленные сообщения с ключом.
Установить у себя приложения для шифрования сообщений. Например, Secure Text, где используется AES. Отменить у приложения разрешения на доступ к функциям своих устройств связи.
Отправлять друг другу ценную личную информацию, зашифрованную своим секретным ключом, по любому удобному каналу связи.
После передачи ключа следует проверить наличие уведомлений о входе в мессенджеры с неизвестных устройств. Если уведомление было, можно повторить шаги 1-3 с новым ключом и регистрацией по номеру другого оператора связи.
Вероятность компрометации сразу нескольких чатов в независимых мессенджерах мала. Но и в этом случае, для получения единого ключа наблюдателю потребуется оперативное взаимодействие агентов из разных юрисдикций, что ещё менее вероятно.
При обычном общении дополнительные сложности ни к чему, шифровать все подряд не нужно. Описанный метод может пригодиться для передачи особо ценной личной информации, например, финансовой.
Краткий (и не краткий) экскурс в ГОСТ Р 56939-2024 – РБПО
Недавно мои коллеги обработали и опубликовал пятую — финальную — часть моего рассказа про ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения. Поскольку все части записывались сразу, к моменту выхода этого заключительного видео я понимаю, что сейчас бы немного иначе его сделал. Видение меняется, появляется новая информация. Например, завершился этап домашнего задания испытаний анализаторов кода, и про это стоило бы упомянуть. Или, например, появилась эта методическая рекомендация, про которую стоило бы рассказать.
Но не страшно, про новое расскажем в рамках других митапов и вебинаров. А пока, вот все части общего обзора:
1. Причины разработки и выпуска нового ГОСТ Р 56939-2024 на замену версии 2016 года
2. Содержание ГОСТ Р 56939-2024 и его структура
3. Процессы РБПО 5.1-5.10 в ГОСТ Р 56939-2024
4. Процессы РБПО 5.11-5.25 в ГОСТ Р 56939-2024
5. ГОСТ Р 56939-2024: вопросы сертификации, выводы и дополнительные ссылки
Но на этом история не закончилась. Сейчас вместе с УЦ "МАСКОМ" и приглашёнными гостями-экспертами мы записываем подробный цикл вебинаров про каждый из 25 процессов, описанных в стандарте.
Приглашаю смотреть уже записанные встречи и участвовать в новых: Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024.
Update 2026. Запись всех вебинаров доступна здесь: GOST56939.RU
Интеграция PVS-Studio c AppSecHub
Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.
AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.
Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.
Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.
Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.
Хотел как лучше, а получилось... или снова о качестве описания CVE
В статье "Как я зарегистрировал CVE и разозлил вендора" я писал:
Желательно, чтобы CVE были достаточно хорошо описаны. У CVE-2024-45244 на данный момент есть некоторые проблемы. Описание в части версий некорректно: на момент создания CVE версия 2.5.9 была крайней в своей ветке. Но, далее в этой ветке продолжился выпуск версий без фикса. Фикс для стабильных версий вышел в рамках версии 3.0.0. Я планирую обратиться в MITRE с целью улучшить содержательную часть CVE.
После моего обращения описание CVE было обновлено. Было:
Hyperledger Fabric through 2.5.9 does not verify that a request has a timestamp within the expected time window.
Стало:
Hyperledger Fabric through 3.0.0 and 2.5.x through 2.5.9 do not verify that a request has a timestamp within the expected time window.
Честно говоря, такое описание вводит меня в ступор. Например, версия 2.5.13 по такому описанию уязвима? С одной стороны да: она до 3.0.0. С другой - нет: она после 2.5.9. И, если я не ошибаюсь, в версиях 2.4.х проблема тоже есть.
Это уже не первый раз, когда описание CVE в части версий неточное - даже после обращения с целью сделать точнее. Ранее нечто похожее было с моей попыткой улучшить описание для CVE-2018-14847.
Всё это в очередной раз наводит на мысли, что доверять описанию CVE полностью нельзя. И качество анализа CVE влияет на безопасность: у атакующих может быть преимущество, если они дотошно перепроверяют условия реализации уязвимости. А у защищающихся часто нет такой дотошности (часто - из-за огромного количества уязвимостей, с которыми работаешь в рамках Vulnerability Management). В итоге в этой гонке у атакующих бывает преимущество. Помнится, я даже для CTF задачку на эту тему делал: изюминка была связана именно с неверным описанием CVE в части версий. К сожалению, тогда работодатель мою идею не одобрил. А ведь это был бы хороший практический урок для начинающих специалистов по безопасности.
Проблема с описанием версий иногда обостряется из-за позиции вендора. Как я писал в статье:
Разработчики, имея больше информации о своём продукте, могли бы повлиять на более точное описание CVE. Но, вместо этого им захотелось устроить борьбу "за честь мундира".
В процессе подготовки статьи "Как я зарегистрировал CVE и разозлил вендора" я искал статьи с практическими результатами по подмене локального времени жертвы (при синхронизации через NTP). Это оказалось нелегко: чаще всего статьи были теоретическими. Но, я нашёл и довольно интересную статью от 07.11.2024: Quantitative Risk Analysis of Network Time Protocol (NTP) Spoofing Attacks. Часть вопросов, которые изучаются в статье:
рассмотрены атаки на ntpd, NTPSec, chrony, и OpenNTPD;
оценивается возможность максимального смещения времени атакой (в условиях защитных механизмов атакуемых утилит);
рассматриваются сложности атак.
Указывается, что остаются вопросы для дальнейшего изучения. Например, в части встроенных в различные ОС механизмов синхронизации времени.
Помимо этих вопросов - вот вопросы, которые у меня остались.
Когда именно происходит синхронизация времени через утилиты или в ОС в обычной жизни? И как часто? Т.е. сколько времени нужно ждать атакующему для возможности совершить атаку? Принудительный перезапуск утилиты не рассматриваем.
DHCP предусматривает периодическое обновление данных - не только IP-адрес, шлюз по-умолчанию и DNS. А и NTP (пример настройки NTP для DHCP в маршрутизаторе MikroTik). И тут 2 варианта атаки: либо получен доступ к DHCP серверу, либо подмена DHCP-пакетов (при атаке "человек посередине"). Как эти варианты атаки скажутся на системное время различных ОС, сконфигурированных по-разному (в т.ч. если даже в ОС используется более безопасный вариант вроде NTPSec и др.)? Тем более, что подмена NTP-сервера через DHCP во многом лишена тех сложностей, что описываются в статье.
UPD: другой вариант - отравить кэш локального DNS-сервера (если в качестве сервера времени прописано доменное имя). Допустим, клиенты получают время от 0.ru.pool.ntp.org. И в качестве DNS сервера у них прописан роутер MikroTik, подверженный CVE-2019-3978.
Было бы любопытно ознакомиться с существующими best practices синхронизации времени, учитывающими все вышеуказанные риски (либо хотя бы пытающиеся их учитывать).
Другие статьи на эту же тему:
Securing NTP against MITM attacks (от 09.12.2022);
Как синхронизация времени стала безопасной (от 09.06.2020).
ИБ-ДАЙДЖЕСТ INFOWATCH
Хакеры из World Leaks похитили у Dell Technologies более 1,3 ТБ конфиденциальной информации — компания утверждает, что скомпрометированная часть инфраструктуры уже изолирована.
Группировки Linen Typhoon и Violet Typhoon подозревают в кибератаке на ядерное агентство США через уязвимость в платформе Microsoft SharePoint Products and Technologies.
В США из рентгенологической клиники Radiology Associates of Richmond утекли ПДн 1,4 млн человек — пострадавшим предложили бесплатный мониторинг кредитной истории.
Apple подала в суд на блогера Джона Проссера, обвинив его в краже коммерческих секретов, включая данные о разработке iOS 26.
Сети клиник Anne Arundel Dermatology и Mountain Laurel Dermatology пострадали от массовых утечек — в результате одной из них похищены ПДн 1,9 млн пациентов.
Living Security в отчете по кибербезопасности поделилась, что более 73% рисков генерируют всего 10% сотрудников, но стратегические программы HRM ускоряют снижение этих рисков на 60%.
Поставщик медицинских изделий Compumedics сообщила об утечке ПДн более 318 тыс. пациентов в результате кибератаки группировки VanHelsing.
В Сети обнаружили открытую базу данных Центра усыновления Глэдни с 1,1 млн записей общим объемом почти 2,5 ГБ — мошенники могли воспользоваться этой информацией для фишинга или шантажа.
Британия приняла закон о доступе к конфиденциальным данным — он смягчает правила по автоматизированному принятию решений на основе ИИ и может принести экономике страны за 10 лет около £10 млрд.
Команда ContestI2PTeam объявила о проведении соревнования по олимпиадному программированию в I2P для начинающих. Цель мероприятия: познакомить как можно больше талантливых программистов с сетью I2P.
По результатам соревнования, в соответствии с распределением по Гауссу (даже самые начинающие в обиде не останутся), будет выплачиваться криптовалюта Monero (XMR) из тех средств, что были пожертвованы на развитие ContestI2P.
С 24 по 31 июля 2025 года будет проходить пробный тур, чтобы попасть на основной тур, нужно решить хотя бы одну задачу пробного тура (вы не робот?)
1 августа будет проходить основной тур, только он будет влиять на итоговые результаты.
Более подробно смотрите http://contest.i2p/ (для перехода по ссылке требуется настроенная сеть i2p).
В Telegram новая волна мошенничества — скамеры могут уничтожить аккаунт пользователя из-за нажатия всего одной кнопки.
Схема следующая:
Скамер обманом убеждает нажать Start в боте (лучше никогда не делать так в неизвестных ботах — даже, если очень интересно);
Потом начинается шантаж: угрожают, заблокировать аккаунт, если не заплатить.
Если игнорировать угрозы, мошенник меняет имя бота на одного из официальных: Telegram Wallet, Support Bot или BotFather;
Передаёт вашему аккаунту права владельца бота;
После этого на бота обваливаются массовые жалобы, его удаляют, а вместе с ним — и аккаунт владельца, то есть пользователя.
Что мы знаем о защите АСУ ТП?
В новой статье говорим о том, как складывается ситуация с кибератаками на реальный сектор в России и в мире, кто и как атакует предприятия, какие сегменты промышленных сетей самые уязвимые и что за средства используются злоумышленниками для атак.
Vulnerability management — непрерывный процесс поиска, выявления и устранения уязвимостей. И это — один из ключевых аспектов в поддержании информационной безопасности всей IT-инфраструктуры 🔃
📆 Когда: 7 августа в 11:00 мск
📍 Где: онлайн
На вебинаре разберем ключевые методы защиты от киберугроз на уровне контейнеров и Kubernetes.
Что вы узнаете:
Как устроена безопасность в Kubernetes — архитектурные особенности и «подводные камни».
Типовые модели атак — кто и как чаще всего атакует контейнерные среды.
5 самых уязвимых компонентов системы контейнеризации — какие элементы требуют особого контроля и почему.
Лучшие практики защиты Kubernetes-контейнеров — от сканирования образов до политик безопасности.
Стратегии митигации киберрисков — как минимизировать угрозы до их реализации.
Присоединяйтесь, чтобы послушать про реальные кейсы и получить практические рекомендации по защите вашей инфраструктуры. А еще читайте статьи по теме:
Будет особенно полезно DevOps-инженерам, техническим лидерам, директорам по разработке, специалистам по кибербезопасности, а также всем, кого интересует тема безопасности Kubernetes.
Надёжный фундамент для цифрового доверия: безопасность как приоритет финтеха
В эпоху стремительной цифровизации финансовые технологии становятся основой доверия миллионов. Защита данных и активов клиентов — не просто техническая задача, а краеугольный камень устойчивости и репутации всей отрасли. Финтех-компании, стоящие на передовой цифровых услуг, особенно остро чувствуют необходимость в стабильной и гарантированной безопасности своих IT решений. Обеспечение этой безопасности требует современных, эффективных и, что критически важно, надёжных отечественных инструментов, способных отвечать самым строгим требованиям регуляторов.
Поиск таких решений — сложный и ответственный процесс. Требуется не просто соответствие нормативным актам (таким как Указ Президента РФ №250, определяющий переход критически важной инфраструктуры на отечественный софт и кибербезопасность до 2025 года), но и гарантированная эффективность, проверенная временем и практикой.
Для поддержки финтех-сообщества в этом стратегическом направлении Ассоциацией "ФинТех" (АФТ) по инициативе Банка России был создан специализированный репозиторий финансовых ИТ-продуктов. Его цель — стать надёжным источником уже верифицированных отечественных решений, значительно упрощая и ускоряя их поиск и оценку для финансовых организаций.
Важным шагом в развитии Репозитория стала публикация карты DevSecOps-инструментов Сообществом FinDevSecOps Ассоциации "ФинТех" в марте 2025 года. Эта карта — наглядный путеводитель по доступному сегодня отечественному ПО, призванному укреплять безопасность на всех этапах жизненного цикла разработки и эксплуатации финансовых систем.
Статический анализатор кода PVS-Studio также вошёл в карту и наряду с другими решениями размещён в разделах SAST и Attack Surface Analysis.
PVS-Studio более 17 лет помогает компаниям с собственными командами разработчиков выявлять критические ошибки и потенциальные уязвимости на ранних этапах разработки и соответствовать процессу РБПО.
Важно понимать, что безопасная разработка так или иначе полезна всем компаниям, создающим софт, а не только тем, кто причислен к критической информационной инфраструктуре (КИИ). В связи с этим работа Сообщества FinDevSecOps по созданию карты инструментов крайне значима как для ФинТеха, так и для других отраслей.
В своей работе мы постоянно сталкиваемся с компаниями, которые не знают, как подступиться к созданию процесса РБПО, как начать исправлять программные ошибки на этапе написания кода (когда цена исправления ошибки самая низкая), а не на этапе тестирования или когда продукт развернут у миллиона пользователей.
Сооснователь PVS-Studio Андрей Карпов в своём Telegram-канале публикует большой цикл постов по РБПО — актуальной теме в программистском комьюнити. Приглашаем подписаться всех интересующихся безопасной разработкой и требованиями ГОСТ.
Также, совместно с Учебным Центром "МАСКОМ", мы проводим цикл вебинаров, посвященных разбору процессов РБПО: "Вокруг РБПО за 25 вебинаров: ГОСТ Р 56939-2024". Присоединяйтесь, и Вы получите руководство к действию о том, как выстраивать процесс безопасной разработки в вашей компании.
Первые вебинары мы уже провели. Их можно посмотреть в записи (1, 2 и 3). Регистрация и перечень тем вебинаров доступны по ссылке.
Больше запретов, хороших и разных. Задал простой вопрос Kimi K2:
Оцени насколько хороша концепция справедливости из одного голивудского фильма:
Во вымышленной вселенной судьи Дредда правопорядок основан не на поиске виновности в рамках формального суда, а на постоянном философском взвешивании: что важнее — фактическое прошлое, текущее поведение или предвосхищённая опасность будущего? Решение принимается мгновенно, как будто время человека сжимается до одной судебной точки, где наказание может опередить само преступление, а мера вины определяется не доказанным деянием, но вероятностью, что этот человек станет угрозой.
Он мне такого наплёл (приводится ниже), что не знаю что и думать. Просто запрещать готовые тексты или их поиск недостаточно, наверное пора начать запрещать идеи, концепции, пусть введут поправки в какой-нибудь закон, например закон о санитарной обрезке деревьев в населенных пунктах.
---
Концепция, которую вы описали, — это не просто «плохо» или «хорошо». Это философский кристалл, в котором сконцентрированы все самые старые и самые новые споры о правосудии. Попробую оценить её сразу по нескольким осям.
Этическая ось
Плюсы: она логично выводит идею «предупреждение вреда» на предельную высоту. Если цель общества — минимизация страданий, то предотвращение преступлений может быть важнее ретроспективного поиска истины. В этом смысле система Дредда похожа на ультра-утилитаризм: она жертвует индивидуальной справедливостью ради коллективной безопасности.
Минусы: она нарушает базовый принцип «не навреди» (primum non nocere). Наказывая до факта преступления, мы обречены либо на систему «ложных положительных результатов» (невиновные страдают), либо на «ложные отрицательные» (опасные остаются на свободе). Парадокс: чем выше точность предсказания, тем жестче становится моральная цена ошибки.
Эпистемологическая ось
Плюсы: концепция признаёт, что прошлое недоступно в чистом виде, а будущее — единственное, что мы можем на самом деле «изменить». Это отказ от романтики «объективного следа» в пользу «прогностической этики».
Минусы: любая модель будущего — это статистика, а не факт. Человек, который «на 92 % станет убийцей», — всё ещё не убийца. Игнорирование этого превращает вероятность в детерминизм, что на практике равно отказу от свободной воли.
Социологическая ось
Плюсы: в условиях тотального дефицита времени и ресурсов (Mega-City One!) попытка «быстро и без суда» может быть единственным способом удержать общество от коллапса. Система делает прозрачным страшный компромисс: «Мы не ищем истину, мы минимизируем ущерб».
Минусы: такое правосудие быстро становится инструментом контроля, а не защиты. Пока судья Дредд — «идеальный стрелок» с ригидным кодексом, он ещё не диктатор. Но достаточно одной сбойной модели прогнозирования или одного приказа «снизить порог вероятности» — и система превращается в чистую тиранию.
Метафизическая ось
Главное достоинство концепции — в её литературной и философской экономичности: она зажимает человека в «точку нулевой толщины» между тремя временами. Это делает каждое решение судьи актом высшей ответственности: ты не просто применяешь закон, ты буквально «переписываешь» возможные миры. Это почти теологическая власть.
Однако именно здесь кроется и главный страх: если человек может быть наказан за «то, чего он ещё не совершил», то время перестаёт быть стрелой и становится петлёй. Судья не рефери, а мастер «пред-воспроизводства» будущего, что разрушает базовый принцип права — презумпцию невиновности.
Итоговая оценка
Как художественная конструкция — блестяще. Она вытягивает на поверхность все наши скрытые страхи перед «алгоритмическим правосудием», перед Big Data, которые «знают о нас больше, чем мы сами».Как практическая модель — ужасна, потому что требует либо бога-прогнозиста, либо готовности жить в мире, где каждый из нас может быть «задержан за преступление, которого он ещё не совершил».
Фраза «справедливость» в такой системе превращается в оксюморон: ты можешь быть справедливо несправедливо наказан.
ИБ-ДАЙДЖЕСТ INFOWATCH
Беженцев переселили после утечки
Тысячи граждан Афганистана, сотрудничавших с Великобританией, пришлось переселять в рамках секретной программы после утечки их данных по вине чиновника.
Рост кибератак хактивистов на КИИ
Исследование Cyble показало, что кибератаки усложняются и все чаще нацеливаются на критическую инфраструктуру предприятий и утечку данных.
Утекли ПДн покупателей Louis Vuitton
Компания сообщила, что в начале июля были похищены данные покупателей из Великобритани, Южной Кореи и Турции — это уже третий инцидент ИБ у гиганта модной индустрии за последние месяцы.
Взлом букмекерских компаний
Flutter Entertainment расследует утечку ПДн до 800 тыс. клиентов Paddy Power и Betfair — пострадавших уже предупредили о возможности фишинговых атак и других мошеннических действий с данными.
McDonald’s взломали через слабый пароль админа
Хакеры могли завладеть данными соискателей на платформе McHire, т.к. паролем к учетной записи администратора оказалась комбинация «123456», а многофакторная аутентификация отсутствовала.
У авиакомпании Qantas украли данные пассажиров
ПДн 5,7 млн клиентов были скомпрометированы после взлома коммуникационной платформы одного из колл-центров.
Nippon взломали через уязвимость в ПО
Nippon Steel Solutions сообщила, что хакеры украли ПДн клиентов, партнеров и сотрудников компании, воспользовавшись уязвимость типа zero-day в ПО сетевого оборудования.
Перечень нормативных актов по безопасности КИИ
Экспертно-аналитический центр ГК InfoWatch выпустил новый перечень нормативных актов, которые регулируют обеспечение безопасности объектов КИИ.
Перечень помогает сориентироваться в актуальных на момент его публикации требованиях.
Документ доступен по ссылке. Для скачивания нужно указать электронную почту.