Все мы видим, что происходит в мире в последние месяцы. Неправомерное давление на нашу страну усиливается на всех уровнях – экономическом, технологическом – и проявляется в форме разнопланового силового воздействия, в том числе кибератаках, проводимых различными акторами, вплоть до APT-группировок. О некоторых атаках – успешных и неуспешных – мы знаем, а о некоторых не узнаем никогда. Поскольку угроза безопасности информационной инфраструктуры носит комплексный характер, то и бороться с ней можно только комплексными методами.
Автор: Дмитрий Пономарев, технический директор ООО НТЦ “Фобос-НТ”, сотрудник ИСП РАН
На стратегическом уровне процессы технологического развития можно выстраивать, опираясь на концепцию "физтеховского треугольника" "образование – разработка – инновации". При создании информационных систем, в частности на уровне непосредственной разработки СЗИ, требуется следовать принципу эшелонированной обороны. И в самом ее фундаменте, когда атакующим пройдены все остальные уровни защиты – организационные, административные, наложенные – находится безопасность разработки. Надежность последнего рубежа, а значит, и всей киберобороны в целом определяется тем, насколько хорошо спроектирована и реализована ваша система.
Необходимость развивать процессы безопасной разработки в отечественных компаниях очевидна, и эта позиция всецело поддерживается государством в лице ФСТЭК России. Обратим внимание на два очень важных документа:
Эти формулировки принципиально важны! В соответствии с ними заявитель обязан тестировать разрабатываемые СЗИ, подлежащие серийному производству, теми же методиками, практиками и инструментами и в том же объеме, которыми лаборатория будет его проверять.
Что это значит? Это значит, что парадигма "отдадим собранный полгода назад комплект бинарных файлов в лабораторию, они там что-то пофаззят, и испытания пройдены", системно больше не работает. Конечно, мир не меняется моментально, некоторые из разработчиков-лицензиатов, пока еще пытающиеся идти упомянутым путем, вполне возможно, сертификаты получат, но точно не все и, возможно, не с первой попытки: глубина экспертизы и количество замечаний и отрицательных заключений со стороны участников процесса сертификации, выполняющих контролирующие функции (органы по сертификации, федеральный регулятор) стремительно нарастает. Можно сделать вывод: если у разработчика не реализован процесс безопасной разработки, отдавать код в испытательную лабораторию бесполезно.
Парадигма "отдадим собранный полгода назад комплект бинарных файлов в лабораторию, они там что-то пофаззят, и испытания пройдены", системно больше не работает
В то же время актуальная нормативно-правовая база содержит и позитивные стимулы для развития процессов безопасной разработки. Артефакты, подтверждающие корректное выполнение требуемых практик, полученные разработчиком в ходе процессов создания СЗИ в парадигме безопасной разработки, допускается переиспользовать в сертификационных испытаниях, что, как правило, приводит к существенному сокращению их сроков.
Практики и методики безопасной разработки должны реализовываться в соответствии с регламентирующими документами. В настоящий момент требования к количественным и качественным характеристикам SDLи сертификационных процессов задаются положением о системе сертификации, требованиями доверия и методикой ВУ и НДВ. Стоит упомянуть и ГОСТ Р 56939–2016 "Защита информации. Разработка безопасного программного обеспечения"3, но важно понимать, что, будучи концептуально правильным, он тем не менее носит рекомендательный характер. Ориентироваться на этот ГОСТ при подготовке продукта к сертификационным испытаниям не совсем верно, поскольку в ряде вопросов (например, аспекты статического и динамического анализа) он гораздо более узок, чем требования и методики регулятора, а в каких-то иных он, наоборот, описывает практики, не подлежащие проверке в ходе сертификационных испытаний (например, обучение персонала методикам и практикам безопасной разработки).
Чтобы внедрить безопасную разработку, недостаточно пройти код парой-тройкой анализаторов и прикрепить к материалам отчеты на 200 тыс. строк с формулировками "уязвимости не эксплуатируемы, потому что не эксплуатируемы". Безопасная разработка – это непрерывный процесс, включающий выделенных сотрудников, технику, платные и бесплатные программные средства. Важно также понимание необходимости этого процесса сотрудниками компании, начиная с собственника и заканчивая джунами-стажерами. Правильным подходом является переход компании в целом к работе в парадигме Secure by Design. Необходимо донести до руководства важность процесса безопасной разработки. Скажу честно, работать с крупными компаниями сложнее, чем с небольшими или средними организациями, где уровень принятия решений – это человек, с которым ты можешь общаться напрямую, которому можно за чашкой кофе объяснить, зачем все это нужно и какую реальную пользу от внедрения получит бизнес. В крупных же компаниях собственник обычно где-то очень далеко, и пытаться до него донести важность безопасной разработки весьма сложно. Но если руководство организации все же проявит нужную политическую волю, вплоть до приостановки процессов разработки на несколько месяцев и концентрации на внедрении практик и инструментов, ориентированных на безопасность, желаемый и ощутимый положительный эффект может быть достигнут очень быстро. И такие прецеденты в российских условиях есть.
Важно понять и принять как аксиому, что правильно поставленный процесс безопасной разработки становится залогом своевременного получения сертификата соответствия, а также настоящим конкурентным преимуществом XXI века.
Для внедрения SDL-практик в команду разработки в количестве 5–15 сотрудников необходимы 1–2 выделенных SDL-специалиста. Важно понимать, что свободных Security Champion на рынке нет. На текущий момент отечественная система образования только приходит к необходимости подготовки специалистов профиля Application Security, одной из первых ласточек является создание учебной программы "Кибербезопасность", благодаря стараниям ФСТЭК России и ИСП РАН, однако реальные плоды этих преобразований мы увидим только через несколько лет. Тем не менее такого специалиста вполне реально вырастить за год-полтора при наличии хороших исходных данных: Junior- или Middle-разработчик по каждому языку программирования, используемому в продукте, с навыками пентеста, общим представлением об анализе уязвимостей, навыками DevOps, горящими глазами и прямыми руками. Важно не брать в SDL чистых билдеров, даже если он Senior Developer на ассемблере, ведь люди, которые любят писать код, делать интересные фичи в приложениях, на позициях SDL не задерживаются. Четверть наших клиентов изначально допустила такую ошибку, и это привело их к затягиванию процесса. Человек, занимающийся SDL, должен любить расследовать, рыться, ковыряться в деталях, у него должен быть подходящий для этого характер и склад ума.
Немаловажным и полезным является подключение кандидатов в SDL-специльность к деятельности профессионального сообщества, формируемого под эгидой центров компетенций ФСТЭК России и ИСП РАН: возможность задать вопросы и получить ответы от более опытных единомышленников именно в отечественном информационном сегменте сложно переоценить.
Безопасная разработка – это не бесплатное и не дешевое удовольствие. Но нужно воспринимать связанные с ней затраты исключительно как инвестиции, которые уже в среднесрочной перспективе начнут приносить качественные результаты.
Приведем один из множества частных примеров: глубокая автоматизация всех основных видов динамического тестирования в "Лаборатории Касперского" позволила сократить релизный цикл стратегически значимых продуктов компании с одного года до одного квартала и при этом повысить качество тестирования, то есть снизить число ошибок, выявляемых на этапе эксплуатации продукта.
Первый пункт затрат, естественно, – инфраструктура, аппаратная платформа, вычислитель. Стоимость его для компании среднего размера можно оценить от 1 млн до 3 млн руб. Впрочем, вполне возможен более оптимизированный по стоимости вариант развертывания инфраструктуры в облаке. Важно понимать, что некоторые практики анализа, в первую очередь фаззинг-тестирование, "съедят" столько процессорных ядер, сколько вы сможете им выделить. В этом смысле фаззинг сравним с майнингом криптовалют: увеличение вкладываемых в анализ ресурсов повышает шанс нахождения уязвимостей раньше потенциального нарушителя, но, разумеется, не гарантирует отсутствие в коде потенциальных уязвимостей.
Второй момент: инструментальные средства потребуют до 5 млн руб. в год в зависимости от конкретных условий. При этом в настоящее время действует льготная программ ИСП РАН, позволяющая получить широкий комплект средств анализа на безвозвмездной основе сроком на полгода [4[.
Третий момент – фонд оплаты труда. Назвать конкретные цифры здесь сложно, поскольку зарплатные политики компаний могут значительно различаться, в том числе в зависимости от региона.
После запуска процесса внедрения SDL-практик значимые результаты появятся, как правило, через 6–12 месяцев. Процесс очень непростой, и чем дальше, тем более сложным он становится, однако также интересным для инженеров и полезным для компании в целом.
Привожу неполный, основной список того, что как компании, так и лаборатории должны уметь делать уже сейчас:
С течением времени этот список будет расти как с точки зрения номенклатуры требуемых практик, так и в плане глубины и качества их применения.
Помимо внедрения самих практик, нельзя забывать о двух важных аспектах:
Если заглянуть в недалекое будущее, то можно увидеть ряд грядущих важных событий и изменений.