«К 2028 году общая стоимость киберпреступлений в мире вырастет почти в 4 раза»

На прошедшем форуме «Будущее Региона 2023» большое внимание было уделено теме информационной безопасности. Этот вопрос становится все более актуальным. О том, почему это важно, как компания может выиграть от внедрения принципов безопасной разработки и что компании и лаборатории должны уметь уже сейчас рассказывает Дмитрий Пономарев, технический директор ООО НТЦ «Фобос-НТ» и сотрудник Института системного программирования им В. П. Иванникова РАН.

«Сейчас важно прививать культуру безопасной разработки и развивать эти процессы в отечественных компаниях»

— Мир меняется, системы становятся все сложнее. И чем сложнее система, тем выше вероятность появления в ней ошибок. Соответственно, если не работает система — не работает бизнес. И один из типов таких проблем – это безопасность архитектуры решения и программного кода и их качество в целом.

Во-первых, сейчас активно растет рынок киберпреступности. По данным сайта statista.com, в последующие пять лет к 2028 году общая стоимость киберпреступлений в мире вырастет почти в 4 раза — с 8.44 до 23.84 триллионов долларов.

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

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

«Принцип "отдадим собранный полгода назад комплект бинарных файлов в лабораторию, они там что-то пофаззят, и испытания пройдены", системно больше не работает»

Позиция относительно необходимости внедрения принципов безопасной разработки всецело поддерживается государством в лице ФСТЭК России. Обратим внимание на два очень важных документа:

Приказ № 76 "Требования по безопасности информации..."1, раздел IV, п. 17, устанавливает, что "тестирование, испытания по выявлению уязвимостей и недекларированных возможностей, а также анализ скрытых каналов проводятся изготовителем в ходе приемочных испытаний средства и испытательной лабораторией в ходе сертификационных испытаний средства".

Приказ № 121 "О внесении изменений в положение о системе сертификации..."2, п. 12, усиливает и конкретизирует требование формулировкой "...при проверке организации производства программных и программно-технических средств защиты информации проверяется внедрение заявителем процедур безопасной разработки программного обеспечения в соответствии с требованиями по безопасности информации, на соответствие которым проводятся сертификационные испытания".

Здесь принципиально важны формулировки. Заявитель обязан тестировать разрабатываемые СЗИ, подлежащие серийному производству, теми же методиками, практиками и инструментами и в том же объеме, которыми лаборатория будет его проверять.

Это значит, что принцип "отдадим собранный полгода назад комплект бинарных файлов в лабораторию, они там что-то пофаззят, и испытания пройдены", системно больше не работает. Конечно, мир не меняется моментально, некоторые из разработчиков-лицензиатов, пока еще пытающиеся идти упомянутым путем, вполне возможно, сертификаты получат, но точно не все и, возможно, не с первой попытки: глубина экспертизы и количество замечаний и отрицательных заключений со стороны участников процесса сертификации, выполняющих контролирующие функции (органы по сертификации, федеральный регулятор) стремительно нарастает. Можно сделать вывод: если у разработчика не реализован процесс безопасной разработки, отдавать код в испытательную лабораторию бесполезно.

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

«Безопасная разработка — это не бесплатное и не дешевое удовольствие»

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

Как сказал мой хороший друг из Лаборатории Касперского Дмитрий Шмойлов: «Повсеместное внедрение и автоматизация процедур тестирования и безопасной разработки позволило сократить релизный цикл основных продуктов компании с 6 месяцев до 2 недель». Это подтверждает практика.

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

Первый пункт затрат, естественно, — инфраструктура, аппаратная платформа, вычислитель. Стоимость его в 2023 году для компании среднего размера можно оценить от 2 млн до 5 млн руб. Впрочем, вполне возможен более оптимизированный по стоимости вариант развертывания инфраструктуры в облаке. Важно понимать, что некоторые практики анализа, в первую очередь фаззинг-тестирование, "съедят" столько процессорных ядер, сколько вы сможете им выделить. При этом, чем больше ресурсов вы выделяете на автоматизированное тестирование, тем выше вероятность, что вы найдёте ошибку в коде ранее, чем это сделает потенциальный нарушитель.

Второй момент — инструментальные средства потребуют до 5 млн руб. в год в зависимости от уровня доверия, на соответствие которому вы проводите сертификационные испытания, а также от реальной заинтересованности организации в поиске ошибок и уязвимостей в коде анализируемого решения.  

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

После запуска процесса внедрения SDL-практик не стоит ждать значимых результатов на следующий день. Как правило, они появляются через 6-12 месяцев. Это довольно непростой процесс, и чем дальше, тем более сложным он становится, однако также интересным для инженеров и полезным для компании в целом.