Основное направление
Безопасность
В фасете «Основное направление» значение «Безопасность» группирует публикации по основной предметной области. В одном месте собраны статьи, открытые источники, институты, компании, люди, региональные риски, операционные зависимости и рыночный контекст. Страница объясняет границы области, основных участников и источники, на которые стоит опираться при сравнении сигналов. Она помогает увидеть, как одна тема проявляется в событиях, профилях, изменениях рынка и долгосрочных инфраструктурных решениях.
Облачные сервисы: тенденции Европы и Ближнего Востока
После сбоя Yandex путь бота важнее его хостинга
Аналитическая справка о После сбоя Yandex путь бота важнее его хостинга объясняет событие, доступные открытые подтверждения, участвующие организации, региональный контекст, рыночные риски и возможные последствия для инфраструктуры. В категории Аналитика: Облачные сервисы…
Облачные сервисы Северной Америки
Предложение Proofpoint о покупке Varonis проверит связь угроз и доступа к данным
Оповещение о риске становится полезным, когда можно установить, кто или какой агент действовал, к каким данным он имел доступ, какое разрешение открыло этот путь и изменило ли реагирование уровень риска. Proofpoint рассчитывает сблизить эти элементы благодаря покупке Varonis.…
Истории
На FIRST при LACNIC 46 CEDIA оставит критические решения CSIRT за людьми
В программе на 21 октября заявлен доклад о DALIA: ИИ поможет CSIRT сортировать и сопоставлять сигналы, но критические решения и сдерживание инцидентов останутся за людьми. В открытом описании не объяснено, как этот предел обеспечивается.
IETF
Правило совпало. Другая реализация увидела другой текст.
Байты письма и Sieve-скрипт могут остаться прежними, а результат после миграции измениться. RFC 5173 оставляет реализации выбор поверхности: сырой недекодированный body, выбранные MIME-части или извлечённый best-effort текст. Именно поверхность, а не слово само по себе…
IETF
Дочерний токен был действителен. Но полномочие должна была доказать вся цепочка.
Безупречная подпись дочернего OAuth-токена подтверждает действие одного ключа, а не право на операцию. Это право возникает только тогда, когда доверенный корень, каждый переход, каждое сужение, актуальный статус и локальная политика ресурсного сервера образуют один непрерывный…
IETF
Производитель подписал новые корни доверия. Сервер доставки всё ещё не был аутентифицирован.
Заводской ключ может разрешить устройству принять пакет операционных CA до того, как оно узнает сервер EST. Но подпись относится к объекту, а не к соединению: локальная политика, новая сессия, регистрация сертификата и работа сервиса требуют отдельных решений и доказательств.
IETF
Литерал выглядел точным. Среда всё ещё выбирала его смысл.
Хеш-подобный литерал производит впечатление завершённого доказательства: видны алгоритм, данные и аккуратная запись. Но до появления значения среда разрешила имя расширения, загрузила конкретный код, применила параметры и локальный список разрешений. Точность записи не устраняет…
IETF
Вставка прошла успешно. Публичный DNS ещё ничего не подтвердил
Зелёное сообщение в панели может означать лишь то, что оператор принял и применил пакет. Авторитетные серверы, вторичные копии, рекурсивные кэши и сервис, ради которого менялась запись, живут дальше по цепочке доказательств.
IETF
Подпись проверилась. Полномочие ключа осталось в таблице партнёров
Самая опасная ошибка при ротации AS2 не обязана выглядеть как криптографический сбой. Канал может быть защищён, имена совпасть, MDN подписаться, MIC сойтись — и всё же новый ключ окажется в строке не того партнёра.
Досье
Отделяемая подпись воспроизвелась. Доказательство всё ещё было неполным
Новый тестовый вектор создаёт убедительный момент: байты совпали, обе математические проверки дали ожидаемый результат, сборка стала зелёной. Но 1 октября 2026 года у восьми новых чисел OpenPGP оставалась ещё одна граница. Ревизия 05 рабочего проекта называла их 37–44, а…
IETF
Ключ ACME сменили. Вчерашнее DNS-разрешение всё ещё действует
Новая редакция постоянной DNS-проверки ACME отделяет ротацию учётных данных от отзыва полномочия. Старый закрытый ключ уже не подпишет запрос, но отпечаток его открытой части может продолжать поддерживать ранее полученную авторизацию.
IETF
Доказательство прошло проверку. Кто теперь отвечает за метку?
Прозрачность ключей способна доказать согласованность ответа каталога с прежней историей. Но она сама не назначает полномочия, доверяющую сторону и обязанность продолжать наблюдение. Именно этот пробел ролей выявила новая проверка IETF.
История
Инциденты, стандарты и институты, которые ушли: что остаётся от IETF WG grip
Рабочая группа IETF, писавшая основы ожиданий от команд реагирования на компьютерные инциденты, завершила работу в декабре 2001 года — но её главный документ до сих пор действует.
Досье
Значение было тем же. Восстановленные байты — нет
Подписывающая и проверяющая стороны вывели одну и ту же карту CBOR: одинаковые ключи, одинаковые значения. Но входы подписи различались. Содержимое никто не менял — два кодировщика воспользовались разными разрешёнными свободами, а протокол так и не назначил, кто должен эти…
Досье
Доказательства не связывались. Оболочка всё равно узнавала человека
Два BBS-доказательства имели разные байты, и по ним нельзя было установить общую подпись. Но оба несли редкий заголовок, десять позиций сообщений, одинаковую необычную пару раскрытых индексов и ключ, выданный группе из двенадцати человек. Криптография выполнила обещание. Система…
Досье
В реестре было `co`, но соединение его не выбирало: RFC 9952
Три команды одновременно объявили успех. Одна показала запись IANA, вторая — SVCB, третья — включённый параметр сервера. Только в трассе не оказалось ALPN. RFC 9952 позволяет понять, почему три правдивых отчёта не складываются в доказательство переговоров.
Досье
Имя осталось AEGIS, а правило повторного использования изменилось: RFC 10032
Генератор потока по определению выбрасывает тег. Ниже по цепочке его вывод всё равно помечают как «аутентифицированный AEGIS»: название семейства сохранилось, а свидетельство исчезло. Ошибка возникла не внутри криптографического раунда, а в присвоении выходу чужих полномочий.
IETF
В IDMEFv2 код 204 подтверждает приём, но не определяет повторный POST
Менеджер способен сохранить тревогу и потерять соединение раньше, чем ответ увидит анализатор. Для отправителя это неопределённость, для получателя — уже успех. Новый проект HTTPS-транспорта даёт 2xx вес, а смысл повторной отправки оставляет альянсу.
Досье
Подпись прошла проверку, но не назвала тех, кто одобрил действие: RFC 9591
В архиве остались сообщение, открытый ключ группы и корректная подпись Schnorr. Этого достаточно, чтобы повторить криптографическую проверку. Этого недостаточно, чтобы назвать участников сессии и доказать их полномочия. FROST из RFC 9591 сворачивает несколько долей подписи в один…
Досье
В списке было EdDSA, но кривая оставалась неназванной: RFC 9864
Совпадение названия алгоритма ещё не означает совпадение возможностей. `EdDSA` не сообщал, поддерживает ли сторона Ed25519, Ed448 или оба варианта. RFC 9864 возвращает обязательный выбор в идентификатор. Это делает переговоры точнее, но не доказывает наличие кода, его включение…