Хотели как безопаснее, получилось как всегда

Хотели как безопаснее, получилось как всегда

Аналитический центр InfoWatch сообщает, что в Торонто были потеряны 3 незашифрованных CD-ROM с персональными данными клиентов банка Scotiabank. Инцидент, как сообщило руководство, произошёл по недосмотру курьерской службы.



«Пакет с тремя CD пропал при внутренней курьерской пересылке из одного отдела в другой, – сообщил в своем письме Джо Конекни (Joe Konecny), представитель банка по связям с общественностью. – По результатам расследования, мы можем утверждать, что диски были ошибочно доставлены в другой отдел. У нас нет оснований полагать, что наши клиенты подвергнутся риску. И мы уведомляем их о происшествии просто в качестве меры предосторожности. Также мы сообщили об инциденте канадскому комиссару по вопросам охраны личной информации».

Диски должны были быть отправлены в канадское агентство по учету доходов (банки обязаны предоставлять агентству информацию). Для внутреннего обмена данными между подразделениями явно был бы удобнее и безопаснее обмен по сети. Однако для внешнего потребителя, чтоб не давать ему доступ в информационную систему банка и не соединять две системы, воспользовались компакт-дисками. Как видим, попытки избежать одного риска привели к реализации риска другого.

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

Количество скомпрометированных записей банк не раскрывает. Он ограничился сообщением, что на дисках находится конфиденциальная информация «незначительного процента» клиентов.

На пропавших дисках содержится информация об именах, почтовых адресах, номерах карт социального страхования, типах и номерах счетов клиентов.
Но одновременно в банке отметили, что на CD-ROM не было выписок из счетов или другой информации о транзакциях и остатках на счетах.

Вышла утилита RKN Block Checker для диагностики блокировок

Разработчик Дмитрий Виноградов представил утилиту RKN Block Checker с открытым исходным кодом. Она помогает понять, почему конкретный сайт не открывается: это обычная сетевая проблема или блокировка на стороне провайдера / регуляторной инфраструктуры.

Проект написан на Python и опубликован под лицензией MIT. Утилита работает из командной строки и проверяет соединение по цепочке DNS → TCP → TLS → HTTP.

Идея простая: не просто выдать вердикт, что сайт недоступен, а показать, на каком именно уровне всё сломалось. Например, если системный DNS не даёт нормальный ответ, а Cloudflare DoH возвращает корректный адрес, это может указывать на DNS-подмену. Если TCP-соединение на 443-й порт сбрасывается, речь может идти о блокировке на уровне IP.

Если TCP проходит, но соединение рвётся на TLS-рукопожатии с SNI, это уже похоже на работу DPI / ТСПУ. А если сайт открывается, но вместо страницы приходит заглушка провайдера или код 451, утилита фиксирует и такой сценарий.

 

Автор отдельно подчёркивает, что смысл RKN Block Checker не в том, чтобы заменить браузер. Браузер и так сообщает, что сайт не открылся. Здесь задача другая — разложить проблему по слоям и дать пользователю более понятную картину, где именно произошёл сбой и на что это похоже.

Утилита сравнивает ответы системного DNS и DNS over HTTPS через Cloudflare, проверяет обычное TCP-подключение, запускает TLS-handshake с SNI целевого домена и затем делает HTTP-запрос. Вердикт выставляется по первому уровню, на котором возникла ошибка.

 

У проекта есть и ограничения. Пока поддерживается только IPv4. Списки целей жёстко заданы в коде и включают около 20 сайтов на категорию, поэтому инструмент не поймает все частные случаи. Кроме того, это разовая проверка без повторов и долгосрочного мониторинга, хотя JSON-вывод можно использовать в cron для регулярных запусков.

RSS: Новости на портале Anti-Malware.ru