Интересный ресурс - проводник по мерам управления безопасностью (security controls) из стандарта ISO 27002:2022. Можно отбирать меры по различным атрибутам. Довольно удобная штука.
https://apps.iso27diy.com/explorer

Консорциум интернет-систем (ISC) выпустил обновления для исправления серьезных уязвимостей в серверном ПО Berkeley Internet Name Domain (BIND).

BIND - это открытая и наиболее распространённая реализация DNS-сервера, обеспечивающая выполнение преобразования DNS-имени в IP-адрес и наоборот. BIND поддерживается организацией Internet Systems Consortium, при этом 10 из 13 корневых серверов DNS работают на BIND, оставшиеся 3 работают на NSD.

Разработчиком устранено четыре ошибки безопасности, две из которых затрагивают BIND версии 9.18. Оба недостатка имеют оценку CVSS 7,0.

Первая из них CVE-2022-0635 описывается как DNAME insist with synth-from-dnssec enabled.

BIND 9.18 проводит рефакторинг synth-from-dnssec (RFC 8198 — агрессивное использование DNSSEC-проверенного кэша) и автоматически включает его для распознавателей, проверяющих dnssec. Ошибка возникает из-за того, что повторяющиеся шаблоны определенных запросов к серверам с включенной этой функцией могут привести к сбою INSIST в query.c:query dname и неожиданному завершению named.

Определенные запросы могут использоваться для инициирования неудачной проверки , которая приводит к завершению указанного процесса. При этом затрагиваются только преобразователи BIND версии 9.18.0 с включенной проверкой dnssec и synth-from-dnssec. Отключение synth-from-dnssec предотвратит уязвимость, но только в качестве временного обходного пути, поскольку эта функция предназначена для защиты зон, подписанных DNSSEC, от псевдослучайных атак поддоменов.

Вторая уязвимость CVE-2022-0667 связана с функцией возобновления dslookup() и может привести к завершению процесса BIND. Пока BIND обрабатывает запрос на запись DS, которую необходимо переслать, он ожидает, пока эта обработка не будет завершена или пока не сработает таймер. Функция не проверяет, была ли загрузка ранее отключена.

Еще одна проблема высокой степени серьезности, решенная ISC, затрагивает версии BIND с 9.11.0 по 9.11.36, с 9.12.0 по 9.16.26 и с 9.17.0 по 9.18.0. Предыдущие версии также могут быть уязвимы.

CVE-2021-25220 (оценка CVSS 6,2) связана с использованием серверов пересылки: фальшивые записи NS, предоставленные этими серверами пересылки или через них, могут быть кэшированы и использованы named, если по какой-либо причине потребуется рекурсия, заставляя его получать и передавать потенциально неправильные ответы. Это может привести к тому, что неверные записи повредят кеш, а запросы будут отправлены не на те серверы.  Таким образом, пользователи могут получить ложную информацию. При этом отключение пересылки или рекурсии предотвращает ошибку.

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

https://www.nccoe.nist.gov/get-involved/attend-events/nccoe-supply-chain-assurance-project-update
Join the National Cybersecurity Center of Excellence (NCCoE) Supply Chain Assurance team for a virtual project update meeting on Wednesday, April 20 at 12 pm EST.

Покупая средства защиты на Авито и иных маркетплейсах, стоит включить в процедуру закупки еще один шаг, - проверку оборудования на предмет закладок, что является нетривиальной задачей. Вообще, для некоторых компаний такой шаг надо было бы проделывать и для закупаемого официально оборудования (знаю две истории, когда отечественный поставщик, упав ниже закупочной цены, выиграл тендер и поставил в госорганы напичканное "недокументированными компонентами" сетевое оборудование). Но сейчас риски выросли для всех, так как Авито врядли можно назвать контролируемым каналом поставки.

Думаю, многим знакома серия книг «для чайников» (for dummies), в которой публикуются обзоры по по той или иной теме. Эти книги являются неплохим введением в тематику, но обладают и определенными недостатками, а именно, определенной рекламной составляющей. Обычно выпуск таких книг спонсируют те или иные компании и в книгах не обходится без скрытой, но чаще открытой рекламы. Но в любом случае такие книги интересны; еще и тем, что они бесплатны и могут быть скачаны с разных сайтов в Интернете. На прежнем блоге я публиковал ссылки на эти сайты, а тут я решил их просто выложить одним архивом, так как получить к ним доступ (хоть они и бесплатны) для пользователей из России стало сложным — то по IP заблокируют, то после заполнения формы с указанием России как места работы никакой реакции.

https://www.sans.org/webcasts/xdr-edr-solutions-forum-2022/

XDR & EDR Solutions Forum 2022

#materials #GDPR

Обновлённая Настольная книга по GDPR.

на RPPA.ru

💬Источник: Алексей Мунтян

Hello everyone! In this episode, I would like to talk about #Github and how to remove sensitive information that was accidentally uploaded there.

This is a fairly common problem. When publishing the project code on Github, developers forget to remove credentials: logins, passwords, tokens. What to do if this becomes known? Well, of course, these credentials must be urgently changed.

What was publicly available on the Internet cannot be completely removed. This data is indexed and copied by some systems. But wiping it from github.com is real.

Why is it not enough to just delete the file in the Github repository? The problem is that the history of changes for the file will remain and everything will be visible there. Surprisingly, there is still no tool in the Github web interface to remove the history for a file. You have to use third-party utilities, one of them is git-filter-repo.

Video: https://youtu.be/FugrD23ix50
Video2 (for Russia): https://vk.com/video-149273431_456239077
Blogpost: https://avleonov.com/2022/03/27/how-to-remove-sensitive-information-from-github-repository/