Вопросы обеспечения безопасности программного кода были важны всегда, и по мере того, как возрастает сложность и ответственность ПО, их значимость неуклонно повышается. Однако во второй половине 1990-х в связи с расширением сферы влияния Интернета актуальность данной проблематики резко усилилась, фактически возникло новое её направление, которое получило название “безопасность ПО” — в данном случае речь идет о надежности программ при возможных внешних попытках нарушить их штатную работу.

В ответ на эти вызовы софтверная отрасль, в первую очередь в лице крупнейших производителей ПО, вынуждена была существенно скорректировать подходы к созданию программ. Процесс был направлен на реализацию следующей ключевой идеи: задача обеспечения безопасности должна пронизывать весь жизненный цикл ПО начиная с формулировки технического задания на его разработку (раньше считалось, что такие вопросы должны решаться на этапе тестирования). Вполне естественно, что этой проблемой озаботилась и Microsoft: в январе 2002 г. Билл Гейтс опубликовал свой меморандум о защите информационных систем, в 2004-м корпорация сформулировала и взяла на вооружение для собственных разработок политику SDL, а спустя пару лет объявила о готовности распространять свои рекомендации и методики в отрасли. Начиная с 2008 г. компания предлагает своим партнерам и корпоративным заказчикам SDL Optimization Model — постоянно обновляемую реферативную модель, позволяющую организациям самостоятельно оценить, насколько полно используется у них опыт обеспечения безопасности при разработке ПО.

О практическом применении SDL в нашей стране говорят уже несколько лет, в том числе вопрос этот регулярно обсуждается на ежегодной российской конференции Microsoft Security Software Development (MSSD). На прошедшей в марте MSSD '2013, как и два года назад, эту концепцию представил старший директор по управлению программами в подразделении безопасности защищенных информационных систем корпорации Microsoft Стив Липнер. В перерыве между докладами с ним побеседовал обозреватель PC Week/RE Андрей Колесов.

PC Week: Методика Microsoft SDL имеет уже почти десятилетнюю историю. Как вы могли бы охарактеризовать прошедший путь, какие изменения произошли за это время?

Стив Липнер: Главным стало то, что система безопасной разработки ПО, о которой десять лет назад говорили лишь в постановочном плане, как о том, что нужно сделать, была действительно создана и, что самое главное, внедрена в практику. Она показала свою эффективность, мы это видим на собственном примере: во многом именно благодаря SDL корпорация Microsoft смогла резко повысить качество своих программных продуктов в плане их безопасности. Это в свою очередь имело два важных результата — во-первых, повышение лояльности и доверия к нам со стороны клиентов, а во-вторых, снижение наших затрат на техническую поддержку и обновление ПО.

Признаком востребованности SDL является то, что методика постоянно обновляется и расширяется: к настоящему времени вышло двенадцать ее версий. Впрочем, такое число обновлений говорит и о высокой динамике развития мира ИТ, изменения в котором нужно отслеживать в процессе создания ПО.

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

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

PC Week: Чем различаются методы SDL при создании традиционного онпремис-ПО и облачных решений, включая и мобильные приложения?

С. Л.: Нужно учитывать, что процесс создания облачных сервисов во многом ориентируется на использование стиля Agile (гибкая быстрая разработка), который, в частности, подразумевает, что ПО обновляется очень часто, можно даже сказать — непрерывно. Идеология SDL изначально ориентировалась на реализацию крупных программных проектов с использованием классической последовательной схемы разработки ПО, поэтому наши усилия по совершенствованию SDL были сосредоточены в основном в направлении ее адаптации к стилю Agile, чтобы обеспечить высокую защищенность приложений в условиях применения гибких методов создания программ.

Мы внесли ряд изменений в SDL c учетом особенностей мобильных систем, в том числе операционной системы Windows RT, используемой на устройствах типа Surface RT. Здесь помимо некоторых вопросов именно программирования нужно было учесть модель распространения приложений через интернет-магазины.

PC Week: Хотелось бы подробнее узнать об использовании идей DSL при разработке в стиле Agile. Все же Agile ассоциируется с той проблемой, что ускорение создания ПО в какой-то мере достигается за счет некоторого снижения качества кода, в том числе в плане безопасности. Как вы в своей методике учли эти моменты?

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

С подобными трудностями столкнулись и мы, поскольку использование уже существовавшей SDL-методики было не очень совместимо с Agile. Мы сделали несколько попыток такой адаптации, которые оказались неудачными. Но потом решение проблемы все же было найдено: один из наших инженеров — он, кстати, выступал с докладом и на нынешней московской конференции — предложил разбить требования SDL на несколько категорий и в каждой группе обязательность выполнения требований рассматривать по отдельности.

Например, есть требование поддерживать в актуальном состоянии компиляторы, что подразумевает проведение некоторой проверки компилятора на безопасность при начале каждого проекта, в том числе при старте работ над новой версией. Но понятно, что такую проверку не нужно выполнять в рамках обновления программы (такие обновленные версии называются sprint) в случае Agile.

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

Как видите, мы использовали гибкий подход к учету SDL-требований, удачно применив его внутри компании при разработке онлайновых сервисов.

PC Week: А как идеи SDL воспринимаются сообществом разработчиков?

С. Л.: Особенностью SDL-методики является то, что мы ее не продаем, она распространяется свободно и бесплатно. Поэтому у нас нет полных сведений о том, кто и как ее использует, хотя, конечно, мы пытаемся следить за практикой и сферой ее применения. Например, SDL применяется, правда, с некоторой адаптацией под конкретные условия предприятия, в таких крупных компаниях, как Cisco, EMC и Adobe. Мы знаем, что SDL используется и в не столь глобальных организациях, в том числе в банковской сфере, в энергетической отрасли. То есть SDL находит спрос в любых структурах, имеют ли они в отделе разработки ПО десятки или тысячи сотрудников.

PC Week: Но все же есть какие-то различия в использовании SDL на разных вертикальных рынках — или в таком разрезе: производители программных продуктов и разработчики заказных решений?

С. Л.: Нет, сколь-нибудь существенных различий мы не наблюдаем. Я уже сказал, что SDL применяется разными по численности коллективами разработчиков. Методика работает и у программных вендоров — ISV, и в компаниях, занимающихся заказными проектами, и в ИТ-отделах предприятий, реализующих внутрифирменные разработки. Широко все это применяется в государственных структурах. Но я еще раз подчеркну, что у нас нет точной статистики использования SDL, мы узнаем об этом в результате общения с партнерами и заказчиками, в том числе на таких конференциях, как вот эта московская.

PC Week: Тогда будет уместен вопрос о ваших впечатлениях о нынешнем мероприятии. Тем более, что вы посещаете Россию уже не в первый раз. Что интересного вы тут видели для себя лично, какие изменения в аудитории заметили?

С. Л.: Я не могу претендовать на глубокое знание того, как процессы разработки ПО организованы в России. Но как я могу судить в ходе таких визитов, эта деятельность находится на достаточно высоком по мировым меркам уровне. Приятно видеть большое число участников конференции, при этом задаются вопросы и по опыту применения SDL в самой корпорации Microsoft, и о возможностях ее использования в собственных компаниях. Хорошая, заинтересованная и понимающая аудитория.

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

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

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

Принципиальное решение данной проблемы здесь базируется на том, что сами процессы разработки ПО должны быть максимально прозрачны для внешних пользователей. Например, вам как пользователю сервиса нужно понимать, насколько его разработчик применяет методы создания безопасного ПО в своей каждодневной деятельности. Сейчас принят стандарт ISO 27034, формулирующий требования к процессам разработки; думаю, что его широкое распространение будет способствовать повышению качества создаваемых комплексных интегрированных решений. В целом же идея обеспечения доверительных отношений должна быть основана на стандартизации и открытости процессов разработки. Еще нужно отметить, что для проверки безопасности используемого ПО совсем не обязательно иметь его исходный код, есть другие не менее эффективные методы решения этих задач.

PC Week: Спасибо за беседу.