|
|
|||||||||||||||||||||||||||||
|
Microsoft: Все продукты должны быть максимально безопасны.Источник: Cnews
Для создания надежной среды вендор предлагает другим производителям пользоваться собственной методологией SDL. CNews: Как в Microsoft контролируют безопасность очередной сборки ПО? Гленн Питтавей: В первую очередь отмечу, что безопасность приложений является для корпорации приоритетом уже в течение многих лет. Это соответствует ожиданием пользователей, живущих в начале XXI века. Наше время мы в компании называем "эрой больших червей", имея в виду Code Red, Nimda и другие подобные разработки. Одним из аспектов обеспечения безопасности приложений в корпорации является формализованный подход, получивший название Security Development Lifecycle (SDL, базирующийся на классической спиральной модели разработки процесс, целью которого является помимо повышения надежности и безопасности ПО еще и сокращение стоимости его поддержки - прим. CNews). Помимо SDL я бы сразу хотел отметить и иной аспект безопасности, другой важный тренд, относящийся к работе с цепочкой поставщиков. В случае Microsoft это в первую очередь сторонние разработчики ПО. Конечным клиентам важно то, как обеспечивается надежность работы всех установленных у них систем. Значит, помимо собственных программ, внимание должно уделяться также и приложениям третьих сторон. Например, это может быть драйвер для той или иной видеокарты. Насколько надежно он написан, защищен ли от добавления вредоносного кода, использовались ли при его создании формальные механизмы, аналогичные SDL внутри Microsoft? Мы применяем безопасную разработку, чтобы сделать лучше Windows и Office, но наши клиенты также оказываются под угрозой и в том случае, если сторонние разработчики Windows-приложений не используют подобные модели в своих бизнес-процессах. Таким образом, нам не достаточно простроить процесс в собственной компании, мы должны сделать SDL доступным, распространить его. Мы публикуем документы, разрабатываем инструменты, продвигаем наш подход к обеспечению безопасности приложений на конференциях. Я считаю, что все продукты должны быть максимально безопасны, и речь идет не только о разработках под ПО Microsoft, подход применим для любых платформ. В современном мире все взаимосвязано и безопасность должна обеспечиваться повсеместно, в любом продукте. Цепочки поставок глобальны - они связывают всех со всеми. В первую очередь в общей надежности совокупности установленных продуктов заинтересованы клиенты из государственного сектора. CNews: Допустим, NVidia хочет включить свой драйвер в поставку ОС. Это накладывает на нее обязательства по использованию SDL? Гленн Питтавей: Здесь мы вторгаемся в несколько иную область. С точки зрения SDL любой разработчик кода должен обеспечить его безопасность для конечного потребителя. В апреле-мае 2012 г. мы расскажем здесь, в Москве о том, как развивался SDL в течение последних лет. Гленн Питтавей: Безопасными продукты делает не открытие исходного кода, а автоматизация поиска потенциальных уязвимостей Существует ряд исследований о важности безопасной разработки приложений, одно из них провел Forrester. Материалы его аналитиков показывают, что принятие формализованного подхода, использование такой практики выгодно с точки зрения возврата инвестиций для самих разработчиков. Другое исследование дает понять, что затраты на программу SDL окупаются даже в случае одной единственной ошибки, которой удастся избежать, благодаря ее применению. CNews: Вы можете назвать вендоров, помимо Microsoft, использующих SDL? Гленн Питтавей: Таких компаний немало, самая известная из них, наверное, Adobe. Производитель использует сходные с нами процессы. Здесь надо отметить, что SDL не является жестко раз и навсегда закрепленным набором правил. Как и в случае с, например, agile-разработкой, каждый из приверженцев стиля применяет его совершенно по-разному, и это нормально. CNews: Как появилась ваша методология? Гленн Питтавей: На сегодня мы уже опубликовали множество документов по методологии SDL. Первая публикация по этой теме принадлежит Майклу Ховарду (Michael Howard) и вышла в 2006 г. Это было скорее описание основных концепций SDL, вряд ли сейчас по ней возможно применить методологию в реальной практике. С тех пор появился целый ряд более детальных документов. Несколько лет назад мы выпустили SDL optimization для разработчиков, которые хотят понять свое текущее состояние с точки зрения методологии и улучшить свои процессы в части безопасной разработки ПО. Затем в 2010 г. мы выпустили Simplified SDL, описывающий, как обычные компании могут использовать наш подход в своей ежедневной практике. CNews: Вы упомянули существующие программные инструменты, что имеется в виду? Гленн Питтавей: У нас есть шаблоны для Visual Studio Team Foundation Server, которые можно использовать в разработке. Также существуют инструменты для моделирования и тому подобные приложения. CNews: Могли бы вы кратко выделить основные идеи, заложенные в SDL? Гленн Питтавей: В первую очередь я бы назвал моделирование на основе потоков (thread modeling). Да, такой подход не уникален и содержится далеко не только в SDL, но в общем виде подобное моделирование крайне теоретизировано, мы же приблизили его к практике. (В SDL моделирование представляет собой цикл из четырех шагов: диаграмма, выделение потоков, упрощение и проверка - прим. CNews). Мы разработали программный инструмент (SDL thread modeling tool, STRIDE), позволяющий вместо привлечения экспертов по безопасности, консультирующих на этапе выделения потоков, сделать это самостоятельно. Этот инструмент также поможет предотвратить еще на этапе разработки такие потенциальные неприятности, как отказ в обслуживании или раскрытие через получение более высокого уровня доступа информации, которая не должна была разглашаться. Обычный разработчик с помощью этого ПО может проанализировать свою программу и воспользоваться рекомендациями SDL. Хочу также выделить второй ключевой момент. Часто о безопасности думают в терминах ревизии кода (code review). Такой просмотр, безусловно, полезен, но когда разработка серьезно ограничена по срокам, то использовать ревизию неудобно. Вам нужен инструмент, автоматизирующий и ускоряющий процесс. Чем больше у вас подобной автоматизации, тем быстрее в итоге движется создание вашего продукта. Существуют статический и динамический анализ кода. Первый может выявить, например, ошибки класса переполнение буфера, второй - реакцию приложения на неверно сформированный входной файл. CNews: Как вы считаете, может ли открытие части исходного кода для сторонних исследователей сделать его безопаснее? Гленн Питтавей: Ваш аргумент выглядит так - чем больше глаз увидят код, тем более безопасным он станет. Но достаточно сравнить по существующей статистике число уязвимостей, найденных в свободном программном обеспечении и проприетарном. Простой просмотр исходного кода большинству людей ничего не даст, не скажет ни о чем. Важно, с помощью какого инструмента вы проводите анализ. Продукт любого размера требует автоматизированного подхода, полноценного динамического анализа. Так что я думаю, приведенная логика об открытости кода не верна. Более безопасными продукты делает не она, а автоматизация поиска потенциальных уязвимостей. CNews: Вы используете только собственные подобные инструменты для автоматического тестирования или сторонние тоже? Гленн Питтавей: Microsoft - это очень большая компания с линейкой очень разных продуктов. Я думаю, что пройдясь по группам разработчиков, вы сможете найти как типовые популярные инструменты сторонних вендоров, так и их собственные разработки. CNews: Нет общего стандарта, регламентирующего применяемые средства? Гленн Питтавей: Нельзя прописать все с точностью до буквы, нужно пробовать разное и проверять качество полученного продукта. Если бы у нас был крайне формализованный процесс, но не было обратной связи от результата разработки, то наши цели не были бы достигнуты. Это тоже важная особенность SDL - мы всегда стараемся понять, каким оказался результат. Методология ежегодно обновляется. Текущая октябрьская редакция предусматривает следующее: при нахождении ошибки в ПО информация о ней отправляется в Microsoft Security Response Center (MSRC). После анализа ошибки мы понимаем, с чем она была связана. Если вдруг оказывается, что найден новый класс проблем, значит что-то должно измениться в новой редакции SDL. Если проблемы такого класса уже были известны до того, значит надо понять, за счет чего она смогла остаться незамеченной при разработке. CNews: SDL развивалась с нуля или что-то было взято за основу? Гленн Питтавей: Разработали методологию мы самостоятельно, но, безусловно, она наследует от других идей. То же моделирование потоков было создано не нами, как и статический анализ. Я думаю, что основное новшество SDL состоит в том, что мы встроили контроль безопасности приложений непосредственно в сам процесс разработки. В этом новизна. В подобных вещах сложно говорить об уникальности, ни у кого нет монополии на удачные идеи. CNews: Вы упомянули заказчиков из госсектора. SDL как-то связан с лицензированием ПО регуляторами? С российским регулированием ФСТЭК, ФСБ? Гленн Питтавей: Дело в том, что сертификация безопасности основное внимание обращает на реализацию определенного числа относящихся к ИБ вещей: контроля доступа и тому подобного. Однако госсертификация сейчас практически не принимает во внимание вещи, важные с точки зрения SDL, такие как уменьшение числа уязвимостей в приложении. Одной из моих зон ответственности в Редмонте является участие в разработке Common Criteria. (Принятые более чем в 20 странах совместные договоренности об определении безопасности ПО - прим. CNews) У них много общего с государственной сертификацией в самых разных частях мира. Различные правительства договорились об общем подходе к сертификации продуктов: помимо США в число признающих Common Criteria стран входят и ведущие европейские экономики. В России, Китае, Индии сертификацию сейчас нужно проходить отдельно. CNews: Спасибо.
|
|