BIS’22: штрафы за утечки, критерии для объектов КИИ, цифровая независимость

BIS’22: штрафы за утечки, критерии для объектов КИИ, цифровая независимость

BIS’22: штрафы за утечки, критерии для объектов КИИ, цифровая независимость

В Москве прошел ежегодный саммит по информационной безопасности Business Information Security Summit. Главная дискуссия собрала основных регуляторов рынка ИБ. Обсуждали модели угроз, санкции и ответственность за утечки.

Пленарную дискуссию с представителями ФСТЭК России, Минцифры, Банка России и Центра компетенций по импортозамещению в сфере ИКТ вела Наталья Касперская, президент ГК InfoWatch, председатель правления АРПП “Отечественный софт”.

Среди основных посылов — необходимость усилить ответственность за утечки.

Потерю данных фиксируют, извиняются, но всё заканчивается небольшими штрафами.

“С утечками мы не справились”, — признает Владимир Бенгин, директор департамента обеспечения кибербезопасности, Минцифры России.

Говорили о необходимости “растить” институт генеральных конструкторов не только по ИБ-решениям, но и по прикладным разработкам. Сейчас этим процессом никто не управляет. На фоне относительно развитой отечественной ИБ-инфраструктуры наблюдается провал с точки зрения стратегии развития прикладных разработок. Всё сводится к решению тактических вопросов, а о стратегии мало кто думает.

“Необходимость перехода на отечественные решения связана с тем, что ещё в 2021 иностранное ПО стали активно использовать для деструктивного воздействия на инфраструктуру”, — говорит Илья Массух, генеральный директор Центра компетенций по импортозамещению в сфере ИКТ.

По его словам, именно этот риск, а не хакеры, стали главным драйвером перехода на российские решения — как аппаратные, так и программные.

Теперь предприятиям, которые массово закупили и внедрили импортные СЗИ, сертифицированные ФСТЭК России, нужно планировать замену, напоминает замдиректора организации Виталий Лютиков:

“Все сертификаты этих СЗИ аннулированы, а поддержка прекращена. Формально требованиям ФСТЭК они не соответствуют. Поэтому надо планировать поэтапно переход на отечественные средства защиты и выставлять требования к разработчикам”.

Мы должны были раньше начать эту работу, добавляет Лютиков:

“Но делаем это только теперь, но делаем и идём к этому, так как вариантов практически нет”.

С принципом заместить “всё” не согласен Вадим Уваров, директор департамента ИБ Банка России.

“Считаю, что не нужно бросаться менять все решения! Должна быть технологическая карта. Есть, конечно, определенные проблемы с оборудованием. И в перспективе нужно будет выработать понимание, как его заменить, — говорит Уваров. — У Банка России есть видение, какие процессы для каких наших организаций могут являться рискованными и как эти риски минимизировать”.

Особенно сложно заместить микросхемы.

“С точки зрения чипов основная надежда будет, наверное, всё-таки на дружественные страны”, — считает Илья Массух. Но в какой-то момент нужно будет налаживать свое производство, добавляет эксперт.

На вопрос о том, как будет меняться регуляторика, Лютиков ответил новостью о скорых изменениях категоризации объектов КИИ. Речь о поправках в приказ № 187. При этом представитель ФСТЭК не стал называть даты возможной корректировки:

“Сроки озвучивать не буду пока, чтобы никого не смущать никого из коллег. Но они будут”.

AppSec.Track научился проверять код, написанный ИИ

AppSec.Track добавил поддержку работы с ИИ и стал первым российским SCA-анализатором, который умеет проверять код прямо в связке с ИИ-ассистентами. Обновление рассчитано в том числе на так называемых «вайб-кодеров» — разработчиков, которые активно используют LLM и ИИ-редакторы для генерации кода.

Новый функционал решает вполне практичную проблему: ИИ всё чаще пишет код сам, но далеко не всегда делает это безопасно.

Модель может «галлюцинировать», предлагать несуществующие пакеты, устаревшие версии библиотек или компоненты с известными уязвимостями. AppSec.Track теперь умеет отлавливать такие ситуации автоматически.

Разработчик может прямо в диалоге с ИИ-ассистентом запросить проверку сгенерированного кода через AppSec.Track. Система проанализирует используемые сторонние компоненты, подсветит потенциальные угрозы и предложит варианты исправления. В основе механизма — протокол MCP (Model Context Protocol), который позволяет безопасно подключать инструменты анализа к LLM.

Как поясняет директор по продукту AppSec.Track Константин Крючков, разработчики всё чаще пишут код «по-новому», а значит, и инструменты анализа должны меняться. Редакторы вроде Cursor или Windsurf уже умеют многое, но им всё равно нужна качественная и актуальная база уязвимостей. Именно её и даёт AppSec.Track, включая учёт внутренних требований безопасности конкретной компании. В итоге даже разработчик без глубокой экспертизы в ИБ может получить более надёжный результат.

Проблема особенно заметна на фоне роста low-coding и vibe-coding подходов. Код создаётся быстрее, а иногда — почти без участия человека, но с точки зрения безопасности в нём могут скрываться неприятные сюрпризы: SQL-инъекции, логические ошибки или небезопасные зависимости. Как отмечает старший управляющий директор AppSec Solutions Антон Башарин, ИИ-ассистенты не заменяют классические практики DevSecOps — особенно когда речь идёт об open source, где информация об угрозах обновляется быстрее, чем обучаются модели.

Новый функционал AppSec.Track ориентирован на профессиональные команды разработки, которые уже внедряют ИИ в свои процессы. Он позволяет сохранить требования Secure by Design и снизить риски даже в условиях активного использования генеративного кода.

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