ЕСТЬ РЕШЕНИЕ
DevSecOps – безопасная разработка программного обеспечения как процесс и образ жизни
АНАСТАСИЯ ГОЛЕВА , руководитель направления информационной безопасности АО « РАСЧЕТНЫЕ РЕШЕНИЯ »
Говорят , не бывает идеальных систем обеспечения безопасности , поскольку в любой системе так или иначе присутствует ряд уязвимостей , и вопрос только в их критичности в настоящее время и оперативности устранения данных уязвимостей в будущем . C данными утверждениями сложно спорить . Однако плох тот солдат …, потому стремиться к совершенству – правильно . Кому же нужны стандарты безопасной разработки программного обеспечения ?
Долгое время бытовала уверенность , что такие стандарты нужны исключительно специализированным организациям , чей бизнес основан на разработке программного обеспечения и их продажи заказчикам . Однако в современном мире , особенно после того , как информационные технологии плотно вошли в каждый дом и поселились в устройствах большинства людей уже независимо от возраста , социального статуса и рода деятельности , разработка ПО – явление , можно сказать , повседневное . Разработку мобильных приложений , а также интернет-сайтов заказывают представители бизнеса любого уровня , начиная от малого и самозанятых граждан . Проверить полученные программные продукты на безопасность задача заказчика , однако далеко не у всех имеются компетенции в данном вопросе . И риск выложить недостаточно безопасный продукт в продуктовую среду – разместить сайт в публичном сегменте интернета , либо опубликовать мобильное приложение в одном из соответствующих магазинов – возрастает . Ни в коем случае нельзя недооценивать компетенции самих разработчиков . Естественно , проверка программного продукта на этапе разработки в ИТ-компаниях должна быть и ведется в большинстве случаев , однако такой проверки без должного контроля со стороны заказчика все же недостаточно . Из этого можно сделать вывод о необходимости по крайней мере информирования заказчиков о процессах безопасной разработки , но в идеале – о внедрении соответствующих процессов в компании даже при условии отсутствия собственного штата специалистов в части разработки и тестирования , по меньшей мере , для решения ряда периодически возникающих задач по разработке программного обеспечения , даже если такие действия выполняются внешними подрядчиками .
Как же внедрить процесс безопасной разработки программного обеспечения или , DevSecOps ( от английских слов « Develop » – « Разработка », « Security » – « Безопасность » и « Operations » – « Операции »)? Суть в том , что процесс обеспечения безопасности должен стать непрерывным , внедриться в процесс разработки программного обеспечения и начаться с малых преобразований в сторону улучшения защищенности разрабатываемой системы , с их постепенным увеличением до максимально возможного уровня .
Можно написать огромное количество документов , утвердить матрицы доступа к информационным ресурсам , однако для внедрения процесса управления безопасной разработкой этого недостаточно . Необходима информированность сотрудников каждой роли в процессе разработки об их функциях не только по основной специальности ( разработчики , аналитики , тестировщики и т . п .), но и в части обеспечения информационной безопасности продукта , анализе защищенности разрабатываемых программ . Разумеется , крупные отечественные и зарубежные компании разарабывают и собственные стандарты в части процессов безопасной разработки , однако при работе с государственными и муниципальными заказчиками , а также в случае отсутствия каких-либо индивидуальных отраслевых или корпоративных стандартов в данной сфере , целесообразно руководствоваться государственными стандартами , речь о которых пойдет ниже .
ГОСТы по безопасной разработке ПО
В России утверждены ГОСТы в части разработки безопасного программного обеспечения :
ГОСТ Р 58412-2019 . Защита информации . Разработка безопасного программного обеспечения . Угрозы безопасности информации при разработке программного обеспечения ( Утвержден Приказом ФСТЭК России № 204-ст от 21.05.2019 г .) 1 ;
ГОСТ Р 56939-2016 . Защита информации . Разработка безопасного программного обеспечения . Общие требования . ( Утвержден Приказом Федерального агентства по техническому регулированию и метрологии № 458-ст от 01.06.2016 г .) 2 .
Говоря об методических рекомендациях со стороны отраслевых регуляторов по безопасной разработке ПО и методикам тестирования невозможно обойти вниманием Центральный Банк России , заявивший о важности обеспечения разработки безопасного программного обеспечения в своем документе « Основные направления развития информационной безопасности кредитно-финансовой сферы на период 2019 – 2021 годов » 3 в 2019 году и выпустивший в 2020 году методический документ под названием « Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций » 4 .
Все вышеуказанные документы содержат методические рекомендации , которые допустимо и целесообразно брать за основу при построении и поддержании функционирования процесса разработки безопасного программного обеспечения .
Однако невозможно спорить о том , что процесс – это все же не набор механических требований , а образ мышления . Порой при первом упоминании о безопасности в среде разработчиков программных продуктов не находится понимания . Поэтому важно донести как для работников , так и для руководителей бизнеса важность этого процесса , в том числе и с экономической точки зрения .
Бизнес-ориентированность процесса DevSecOps
Не секрет , что каждый специалист в штате стоит определенного количества средств , и в нынешних , достаточно жестких экономических условиях , необоснованное расширение штата даже на одного-двух сотрудников является порой фатальной ошибкой . Как и в любом вопросе , касающемся бизнеса , в процессах обеспечения безопасности важно найти « золотую середину », компромисс , при котором защищенность информации будет расти без ущерба продуктивности работы сотрудников и , тем более , без ущерба функциональности , быстродействию и юзабилити интерфейсов программных продуктов , которыми пользуются клиенты компании .
По этой причине важно регулярно разъяснять и напоминать сотрудникам о том , что безопасность – да , не всегда приносит деньги , но помогает их не потерять . Клиентам , компании , а далее , в конечном счете , и самим сотрудникам , поскольку стабильность компании – результат их деятельности .
К чему можно прийти ?
Осуществление проверки безопасности программного обеспечения на всем протяжении жизненного цикла разработки продукта . Зачастую проверяются лишь выборочные версии , причиной тому необходимость отчитываться перед внешними или внутренними регулирующими органами , а также обычная значительная загруженность специалистов по безопасности . Данный подход не совсем верен , проверки безопасности должны выполняться на всех этапах .
Автоматизация . Минимизация « ручного труда » сослужит хорошую службу в деле повышения защищенности программного продукта , поскольку исключит максимально возможное количество ошибок , вызванных человеческим фактором . Процесс автоматизации трудозатратен и требует высоких компетенций сотрудников , однако также он экономит бесценное время в дальнейшем .
Регламентация . Крайне позитивно видеть , когда в компании все сотрудники находятся хотя бы примерно в едином информационном поле , а элементарные процессы , в данном случае , в части разработки программного обеспечения , регламентированы , и всем известно , какие процедуры нужно выполнять , какие заявки создавать , кому их направлять , и в какие сроки они будут согласованы или выполнены .
Интеграция процесса анализа защищенности в процесс разработки ПО . Существует понятие непрерывной интеграции или « CI / CD » ( в переводе с английского , « Continious Integration / Continious Delivery » – « Непрерывная интеграция , непрерывное развертывание ( программного продукта )»). При этом , частое внесение изменений в программное обеспечение должно сопровождаться тестированием , в том числе , тестированием защищенности , и развертыванием продукта . Это лишь один из вариантов построения процесса безопасной разработки .
Контроль и управление доступом к ресурсам разработки . Многие компании не имеют собственного штата разработчиков и пользуются аутсорсом , на постоянной и разовой основе . Управление доступом в данной ситуации не должно основываться только на юридических обязательствах сотрудников ( подписание обязательств о неразглашении и т . п .), но должно базироваться на процессе централизованного предоставления доступа к ресурсам разработки программного обеспечения со стороны профильного структурного подразделения заказчика .
Управление привилегированными учетными записями и паролями к ним . Учетные записи разработчиков и других ИТ-специалистов , участвующих в процессе разработки программного обеспечения – привилегированные , то есть , наделенные широкими полномочиями . При помощи таких учетных записей можно осуществлять как позитивные , так и негативные преобразования в информационных системах . В обязательном порядке должен осуществляться регулярный контроль использования предоставленного доступа , его актуализация , в том числе , и в сторону ограничения доступа до минимально необходимого сотруднику в соответствии с его ролью в проекте и функциональными обязанностями .
Унификация . В настоящее время в процессах разработки программного обеспечения присутствует использование значительного количества информационных систем для документирования , тестирования , создания и хранения исходного кода , управления проектами разработки и т . п . В случае , если в компании не одна , а несколько команд разработки , они гипотетически могут использовать разные системы для своей деятельности . Такие процессы лучше унифицировать , поскольку коллективу иногда свойственно меняться , и должно присутствовать четкое понимание того , где хранится и как обрабатывается столь важная информация о разработке программного обеспечения .
Создать в компании идеологию безопасной разработки – вполне посильно при определенном упорстве , поскольку процесс повышения защищенности продукта не просто работа , а еще и крайне интересный процесс , при котором на глазах сотрудников и при их непосредственном участии происходит маленькое чудо – повышение безопасности программного обеспечения .
1 https :// fstec . ru / tk-362 / deyatelnost-tk362 / 305- prikazy / 1858-prikaz-ot-21-maya-2019-g-n-204-st
2 http :// docs . cntd . ru / document / 1200135525
3 http :// www . cbr . ru / content / document / file / 83253 / onrib _ 2021 . pdf
4 https :// www . cbr . ru / information _ security / acts /