43% утечек в Юго-Восточной Азии приходятся на государственные органы

43% утечек в Юго-Восточной Азии приходятся на государственные органы

43% утечек в Юго-Восточной Азии приходятся на государственные органы

Аналитический центр InfoWatch представил исследование утечек информации ограниченного доступа из организаций в странах Юго-Восточной Азии, Южной Корее, Индии и Бангладеш в 2016-2017 годах. В фокус исследования попали сообщения о компрометации данных коммерческих и некоммерческих организаций, а также государственных органов, которые были обнародованы в СМИ и иных открытых источниках.

Как и во всем мире, большая часть скомпрометированных в исследуемом регионе данных пришлась на «внутренних» нарушителей. Виновниками 56% утечек данных из организаций в странах ЮВА, Южной Кореи, Индии и Бангладеш стали сотрудники, руководители и подрядчики, которые имели легитимный доступ к конфиденциальной информации, стали причиной. В сравнении с общемировыми тенденциями исследуемый регион отличается  распределением утечек по пострадавшим отраслям и типам скомпрометированных данных.

В странах ЮВА, Южной Корее, Индии и Бангладеш доля утечек данных, жертвами которых стали государственные органы и силовые ведомства, составила 43%, в то время как в мире этот показатель не превышал 13%. На долю утечек конфиденциальной информации из медицинских учреждений в исследуемом регионе пришлось около 2% случаев, тогда как на общемировой выборке их доля составляла более 16%.

«Утечки больших массивов данных из государственных структур свойственны многим странам, — сказал аналитик ГК InfoWatch Сергей Хайрук. — Например, в 2016 году в сети появилась база данных около 50 млн жителей Турции, а годом ранее были скомпрометированы данные почти 200 млн американских избирателей. Как правило, это связано с  тем, что общий уровень информационной безопасности не успевает за цифровизацией экономических, политических и общественных процессов».

Как и на глобальной выборке, более 90% случаев утечек информации в странах Юго-Восточной Азии, Южной Корее, Индии и Бангладеш сопровождались компрометацией  «чувствительных данных». В исследуемом регионе в 77% инцидентов страдали персональные данные, еще 15% случаев пришлось на компрометацию платежной информации.  В мире платежные данные страдали чуть чаще – примерно в каждом третьем случае утечки. 

 

  

«Стремление стран ЮВА, Южной Кореи, Индии и Бангладеш повысить уровень защиты информации следует в русле общемировых тенденций.— Как и в других странах, здесь происходит ужесточение законодательства в области персональных данных, организации все чаще используют средства защиты информации от воздействия внешнего и внутреннего нарушителей», — отметил Сергей Хайрук.

 

  

 

Самыми популярными каналами утечек в исследуемом регионе оказались браузер и облачные хранилища – на них пришлось почти 74% случаев, потеря оборудования и мессенджеры в совокупности стали причиной 14% утечек. В общемировой выборке на утечки данных через браузер и облачные хранилища пришелся 61% инцидентов, через электронную почту – 23% случаев, на кражу конфиденциальной информации в бумажной версии – 8% утечек. 

 

  

Критическую уязвимость в ядре Linux x86 не замечали с 2020 года

В ядре Linux обнаружили уязвимость, которая тихо жила в системе несколько лет — и притом в одном из самых чувствительных мест. Речь идёт о механизме обработки page fault на архитектуре x86, то есть о коде, который срабатывает каждый раз, когда процессор фиксирует некорректный доступ к памяти.

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

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

На уязвимость обратил внимание инженер Intel Седрик Син (Cedric Xing), внимательно изучавший код обработки исключений. Как выяснилось, логика в функции do_page_fault() опиралась на устаревшее и, по сути, ошибочное допущение.

В комментариях прямо говорилось, что отследить состояние прерываний на всех возможных ветках выполнения почти невозможно — и разработчики много лет балансировали между «комбинаторным кошмаром» из патчей и попытками аккуратно чинить отдельные случаи.

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

Существуют ситуации, когда обращение идёт к памяти ядра, но в пользовательском контексте. В таких случаях некоторые ветки обработчика могли повторно включить прерывания — и вернуть управление туда, где ядро было уверено, что они всё ещё выключены.

Особенно показательной оказалась ветка __bad_area_nosemaphore(), где предпринимается попытка «восстановить правильное состояние», но на деле это происходило не всегда и не одинаково. В результате возникала асимметрия: в зависимости от пути выполнения система могла оказаться в неожиданном состоянии.

В итоге разработчики пришли к простому, но радикальному выводу: латать отдельные ветки бессмысленно. Вместо этого было принято решение гарантированно и безусловно отключать прерывания в одном конкретном месте — прямо перед возвратом управления в низкоуровневый обработчик page fault. Без условий, без проверок, без попыток «угадать» контекст.

Патчи уже вошли в ветку Linux 6.19, а также планируются к бэкпорту в поддерживаемые стабильные версии. Фактически оно устраняет дефект, появившийся ещё во времена Linux 5.8.

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