Утечки, атаки на инфраструктуру и DDoS: компании расставили приоритеты

Утечки, атаки на инфраструктуру и DDoS: компании расставили приоритеты

Утечки, атаки на инфраструктуру и DDoS: компании расставили приоритеты

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

Утечки, атаки на сетевую инфраструктуру и DDoS-атаки. Таковы приоритеты отечественных компаний в плане киберзащиты по итогам года. Исследование для “Известий” провел аналитический центр “Гарда Технологии”.

Осенью эксперты опросили 500 специалистов из Москвы, Санкт-Петербурга, Екатеринбурга и других крупных городов. В пул вошли представители коммерческих и государственных структур, ответственных за информационную безопасность.

Лидерами потенциальных угроз респонденты назвали утечку конфиденциальной информации (20%), атаки на сетевую инфраструктуру (19%), DDoS-атаки (17%).

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

Например, бороться с DDoS-атаками не планируют 8% опрошенных, хотя они и отметили актуальность этой угрозы. Противостоять сетевым атакам на инфраструктуру не собираются 15%, устанавливать защиту от утечек конфиденциальной информации — 9%.

Актуальность угроз меняется в зависимости от сферы деятельности компании.

Согласно исследованию, для телекоммуникационной отрасли на первое место выходит защита от атак на сетевую инфраструктуру (33%), для нефтегазовой — утечки конфиденциальных данных и защита от вредоносных программ (по 22%).

В этом году компании активнее проводят тестирование на проникновение (пентест), киберучения, работают над повышением осведомленности сотрудников в области кибербезопасности, подключают antiDDoS-сервисы, если не сделали этого раньше.

Многие заменяют иностранные ИБ-продукты, которые перестали обновляться, и встраивают новые решения в свои процессы.

Вырос спрос на внешние сервисы и услуги. Речь о SOC, сопровождении и техподдержке ИБ-решений специализированными компаниями, если у самой организации не хватает компетенций и ресурсов.

Уходящий год показал неготовность многих компаний и организаций даже к простейшим кибератакам. По оценкам “РТК-Солар”, в половине инцидентов злоумышленники с невысокой квалификацией достигали цели менее чем за два дня. При этом они почти не скрывали свои действия и даже базовый мониторинг ИБ выявил бы их присутствие в инфраструктуре.

Серьезным вызовом года стала и нехватка отечественного “железа”. Теме аппаратного обеспечения российского ИБ был посвящен недавний эфир AM Live. А 22 декабря мы подведем итоги года. Регистрируйтесь, чтобы не пропустить.

Вышла утилита 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