Операторов ИС ПДн хотят обязать присоединиться к проекту ГосСОПКА

Операторов ИС ПДн хотят обязать присоединиться к проекту ГосСОПКА

Операторов ИС ПДн хотят обязать присоединиться к проекту ГосСОПКА

В Государственную Думу внесены на рассмотрение поправки к законам, касающимся защиты данных. В частности, авторы инициативы предлагают дополнить список мер обеспечения безопасности, закрепленных Федеральным законом «О персональных данных», формулировками, согласно которым операторы информационных систем персональных данных (ИС ПДн) должны будут в обязательном порядке взаимодействовать с системой ГосСОПКА.

Создание системы обнаружения, предупреждения и ликвидации компьютерных атак на информационные ресурсы РФ (ГосСОПКА) было изначально продиктовано необходимостью надежно защитить критически важные объекты (КИИ) от масштабных угроз вроде Conficker и WannaCry. Первые технические решения в рамках проекта ГосСОПКА были опробованы в 2016 году, позднее ФСБ создало ядро системы и сформировало Национальный координационный центр по компьютерным инцидентам (НКЦКИ) для взаимодействия с субъектами КИИ.

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

В частности, был предложен ряд поправок к закону «О государственной защите судей, должностных лиц правоохранительных и контролирующих органов» (No 45-ФЗ от 20 апреля 1995 года). Авторы законодательной инициативы считают нужным уточнить основания и порядок применения меры государственной защиты в виде обеспечения конфиденциальности сведений о защищаемых лицах и их имуществе.

Закон «Об оперативно-розыскной деятельности» (No 144-ФЗ от 12 августа 1995 года) предложено дополнить статьей 12.1 «Недопустимость разглашения сведений об осуществлении оперативно-розыскной деятельности». Речь идет о содержимом официальных запросов на предоставление ПДн, которое организации не должны сливать на сторону (например, в СМИ) без ведома и разрешения источника запроса.

Внесение изменений в закон «О персональных данных» (No 152-ФЗ от 27 июля 2006 года) касается части 2 статьи 19, определяющей меры, которые оператору следует принять для обеспечения безопасности обработки ПДн. Авторы нового законопроекта предлагают расширить формулировки пп. 6 и 9, дополнив их упоминанием ГосСОПКА как гаранта безопасности ПДн:

  • п. 6, закрепляющий такую меру защиты, как обнаружение фактов несанкционированного доступа к персональным данным и принятие мер, предлагается дополнить словами «, в том числе мер по обнаружению, предупреждению и ликвидации последствий компьютерных атак на информационные системы персональных данных и по реагированию на компьютерные инциденты в них»;
  • п. 9, обязывающий операторов ПДн контролировать принимаемые меры по обеспечению безопасности персональных данных и уровень защищенности соответствующих ИС, предлагается дополнить словами «, включая организацию и осуществление взаимодействия с государственной системой обнаружения, предупреждения и ликвидации компьютерных атак на информационные ресурсы Российской Федерации».

Критическую уязвимость в ядре 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