В России хотят увеличить штрафы за утечку персональных данных в 10 раз

В России хотят увеличить штрафы за утечку персональных данных в 10 раз

В России хотят увеличить штрафы за утечку персональных данных в 10 раз

В России предлагают увеличить максимальные штрафы за утечку персональных данных. Согласно новой редакции КоАП, эти суммы вырастут в десять раз — с 50 тысяч до 500 тысяч рублей. Эксперты обеспокоены такими жёсткими мерами, поскольку они могут стать критическими для бизнеса в непростой период пандемии.

Точка зрения поддерживающих увеличение суммы штрафов вполне логична: персональные данные являются одним из самых ходовых товаров на чёрных онлайн-рынках, следовательно, штрафы должны быть по-настоящему высокими, чтобы успешно бороться с утечками.

Согласно проекту новой редакции КоАП, размещённому на ресурсе regulation.gov.ru, штрафы могут вырасти с 50 до 500 тысяч рублей для юридических лиц, с 20 до 300 тыс. для ИП, для должностных лиц — с 10 до 100 тысяч, обычных граждан — с 2 тыс. до 20 тыс.

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

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

Особенно в этом случае пострадает малый бизнес, для которого 500 тысяч рублей могут стать критической суммой, передаёт «Ъ» прогнозы специалистов.

Утечки данных, однако, на сегодняшний день остаются одним из самых актуальных вопросов информационной безопасности. Например, по данным InfoWatch, за 2019 год в мире утекли 13,7 млрд записей персональных данных.

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

Группа компаний «Солар» проверила, насколько хорошо большие языковые модели справляются с двумя самыми трудоёмкими задачами в безопасной разработке — триажем уязвимостей и их исправлением в коде. Итог исследования получился довольно показательный: популярные общедоступные модели ускоряют работу, но пока слишком часто ошибаются, чтобы полностью на них полагаться.

Эксперты Solar appScreener протестировали шесть LLM на 20 крупных приложениях на Java и Python, каждое объёмом более 100 тысяч строк кода. Для анализа использовали как облачные модели — GigaChat 3 PRO, ChatGPT 5.2 и DeepSeek 3.2, так и локальные решения on-premise, включая ChatGPT OSS, Mistral и специализированные модели DerTriage и DerCodeFix.

Сначала с помощью SAST-анализа в проектах нашли около 12 тысяч уникальных срабатываний, из которых почти 20% пришлись на уязвимости высокой критичности. После этого все модели получили одинаковый промпт с описанием уязвимости, фрагментом кода, трассой достижимости и идентификаторами CWE.

На этапе триажа результаты оказались неровными. В Java-проектах среди облачных моделей лучше всех выступил ChatGPT с точностью 60,9%, а DeepSeek показал лишь 50%. В Python-коде картина поменялась: DeepSeek добрался до 80%+, а ChatGPT показал 52,7%. Но лучший результат среди локальных решений продемонстрировала DerTriage — более 80% точности и для Java, и для Python.

С кодфиксом ситуация похожая. Для Java ChatGPT показал 61,8% точности, DeepSeek — 45,5%. В Python их показатели составили 46,6% и 44,8% соответственно. Локальная модель DerCodeFix снова оказалась впереди: 78,2% точности на Java и 83,1% на Python.

Главный вывод исследования простой: LLM действительно экономят время, но на самых ответственных этапах безопасной разработки универсальные модели пока не дают нужной надёжности. Если команда безоговорочно доверится таким инструментам, есть риск пропустить критичные уязвимости.

В «Соларе» также напоминают ещё об одной проблеме: использование облачных моделей может стать каналом утечки исходного кода. Поэтому для задач безопасной разработки компания рекомендует смотреть в сторону локальных моделей on-premise, которые работают в закрытом контуре и всё равно требуют проверки со стороны AppSec-инженера.

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