Безопасная разработка программного обеспечения – основа доверия к ИКТ в условиях современных киберугроз

Уровень угроз в ИКТ



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

По данным сайта CVE Details (http://www.cvedetails.com), только за первые три квартала 2015 года было выявлено около 5 тыс. уязвимостей, почти 800 из которых являлись критическими (рис. 1). Т.е. каждый день в различных продуктах эксперты обнаруживают по 3 критических уязвимости, и это только видимая часть айсберга. Информация об уязвимостях нулевого дня и инструменты для их эксплуатации (exploit) представляют собой ценный «товар», которым начинают торговать и обмениваться на специализированных сайтах.



Статистическая информация по инцидентам ИБ (http://www.hackmageddon.com/) за 2014 год показывает, что в качестве основных целей злоумышленников фигурируют правительственные, индустриальные и банковские информационные системы (рис.2), таким образом вопросы безопасности выходят за рамки отдельно взятого субъекта и затрагивают интересы государства в целом. Это естественным образом нашло свое отражение в действиях регуляторов, которые начали уделять очень пристальное внимание безопасности решений, применяемых в государственных информационных системах и для защиты критически важных объектов.

Так, например, в приказе ФСТЭК России №17 от 11.02.2013 об утверждении требований о защите информации, содержащейся в государственных информационных системах, явно указывается необходимость в ходе внедрения и эксплуатации информационной системы проводить анализ на наличие уязвимостей и принимать меры по их устранению. А в рамках Указа Президента РФ от 03.02.2012 №803 указано, что основной целью государственной политики в области обеспечения безопасности АСУТП является снижение рисков неконтролируемого вмешательства в работу критически важных объектов, а также минимизация последствий такого вмешательства.

Разработка безопасного ПО

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

Но как можно гарантировать безопасность решения и убедиться в том, что исправления уязвимостей будут поставляться своевременно? Ведь даже реализация всех требований по определенному классу защищенности и анализ продукта на НДВ не может исключить вероятности обнаружения в нем уязвимости в процессе эксплуатации. Именно поэтому ФСТЭК России решила взять на вооружение практики по разработке безопасного ПО и инициировала разработку соответствующего стандарта – «Разработка безопасного программного обеспечения. Общие требования».

Процесс разработки безопасного ПО (SDL – Security Development Lifecycle) впервые был разработан и внедрен в компании Microsoft в 2004-м году. С тех пор он доказал свою эффективность и начал использоваться в большинстве всемирно известных компаний, в той или иной степени относящихся к информационной безопасности. Более того, в рамках международной организации по стандартизации ИСО/МЭК начата разработка стандартов серии 27034, посвященных безопасности приложений. Первый стандарт из данной серии был утвержден в виде национального стандарта ГОСТ Р ИСО/МЭК 27034-1 и введен в действие с 1 июня 2015 года. Но данный стандарт больше посвящен методологическому описанию процесса разработки безопасного ПО, в то время как разработанный по запросу ФСТЭК России документ можно рассматривать как методические рекомендации по применению практик разработки безопасного ПО для продуктов, проходящих сертификацию.

Процесс разработки безопасного ПО представляет собой набор дополнительных практик, применяемых на каждом этапе жизненного цикла продукта (рис.3). При этом нужно ясно осознавать, что даже самый навороченный процесс не сможет гарантировать безопасность решения на 100%, поэтому имеет смысл говорить лишь об обеспечении достаточного уровня доверия, адекватного для решения той или иной задачи. Таким образом, перечень применяемых практик должен определяться исходя из специфики продукта и текущего состояния процессов разработки. Если рассматривать практики в отдельности, то большинство из них выглядят достаточно очевидными, но вряд ли большинство компаний применяют хотя бы половину из них. В то время как основной эффект от SDL возникает не от разового применения отдельных практик, а вследствие организации системного подхода в вопросах, связанных с безопасностью. Только благодаря сбалансированному и комплексному применению практик можно добиться эффективного результата. При этом в процесс вовлекаются абсолютно все роли, начиная от руководства компании и менеджеров и заканчивая тестировщиками и документаторами, тем самым формируя культуру по разработке безопасного ПО.



Как проверить безопасность решения

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

Для того, чтобы получить более полную картину о состоянии безопасности продукта, необходимо провести анализ на проникновение и выполнить ряд дополнительных практик по аудиту. Компании, занимающиеся разработкой ПО, уже давно сошлись во мнении, что нельзя доверять программистам проверять качество собственных решений и это дело стоит поручить выделенным специалистам. То же самое касается и тестирования продуктов на безопасность, только в этом случае навыков обычных тестировщиков и тест-дизайнеров будет уже недостаточно и потребуется привлечение экспертов, специализирующихся на проведении тестов на проникновение. Создавать собственную лабораторию по тестированию продуктов на проникновение (penetration test) внутри компании-разработчика может быть экономически нецелесообразно, поэтому этот процесс вполне можно вынести на аутсорсинг (outsourcing), оговорив при этом соответствующие ограничения в соглашении о неразглашении конфиденциальной информации (NDA).

Анализ продуктов на уязвимости может быть инициирован как со стороны компании-разработчика, так и со стороны заказчика решения. В случае, если анализ безопасности решения инициирован со стороны разработчика, возможно повысить эффективность взаимодействия за счет подключения исследователей на более ранних этапах разработки, таких как проектирование архитектуры, а также за счет организации фаззинг-тестирования с учетом специфики конкретного приложения (прим. fuzzing - технология тестирования программного обеспечения, когда вместо ожидаемых входных данных программе передаются случайные или специально сформированные данные).

Для заказчика же подобные компании могут предложить аудит безопасности информационной системы в целом, наладить процесс мониторинга событий безопасности и принять участие в разборе инцидентов безопасности.

Оправданы ли затраты на безопасность?

В завершении статьи хочется привести несколько аргументов в пользу внедрения практик по разработке безопасного ПО. Несмотря на то, что требования по безопасности продуктов диктуются регуляторами, всегда есть желание немного сэкономить и потратить деньги на более полезную/интересную функциональность. При этом добавление новых мер защиты сверх того, что явно оговаривается в требованиях на сертификацию, может восприниматься менеджментом как дополнительные непроизводительные расходы. Поэтому для внедрения практик по разработке безопасного ПО очень важно правильно позиционировать затраты на безопасность — это не издержки, а инвестиции, причем они могут быть достаточно выгодными. Большинство разработчиков ПО знает, что выявление дефектов на более ранних этапах разработки позволяет значительно снизить затраты на их устранение, причем стоимость порой может различаться на несколько порядков, то же самое касается и исправления уязвимостей. Кроме того, если вы стараетесь выявлять и устранять слабости (weakness) своего продукта на ранних стадиях разработки, то вы можете управлять объемом инвестиций и планировать этапность работ, если же уязвимости обнаружены в функционирующей системе, то разработчик вынужден отбросить все плановые работы и заняться срочным тушением пожара. В большинстве случаев риски по срыву плановых работ и репутационные издержки компании в связи с наличием уязвимостей в ее продуктах заметно превышают стоимость планомерного внедрения практик по разработке безопасного ПО. В качестве дополнительного бонуса от внедрения данных практик компания упорядочивает и улучшает базовые процессы разработки, а также повышает качество своих продуктов в целом.

Автор: А. Иванов