Инспекторы программного кода
АрхивИнтерактивВ программных продуктах периодически обнаруживаются различные уязвимости. Для того чтобы их было как можно меньше, в недрах Microsoft были разработаны методики SDL. О них мы беседуем с Иваном Медведевым, главным разработчиком средств безопасности кода в Microsoft.
Для предотвращения уязвимостей в программном коде Microsoft продвигает набор методик безопасной разработки Security Development Lifecycle. Его суть состоит в том, что о возможных проблемах, связанных с безопасностью, разработчики начинают думать на самом раннем этапе создания программного продукта. Разумеется, редмондский гигант заинтересован, чтобы и сторонние производители софта также заботились о безопасности своих программ как можно раньше, а не после того, как кто-то обнаружит в них дыры. И хорошо, если этот "кто-то" окажется независимым экспертом по безопасности, а не злоумышленником.
Для того чтобы рассказать о SDL российским разработчикам, в Москву из Редмонда приехал Иван Медведев, наш соотечественник и глава группы по разработке внутренних средств по безопасности ПО. Мы задали ему несколько вопросов.
- Как Вы попали в Microsoft и чем сейчас занимаетесь в корпорации?
- После окончания в 1998 году факультета ВМК Московского университета я работал в одной российской компании, которая занималась шифрованием IP-потоков. Собственно, работать я там начал еще во время учебы. Затем часть моих однокурсников решили уехать на работу в Microsoft. Дело в том, что представители корпорации приезжали в Россию и специально набирали людей для работы над различными проектами. Нескольких человек из моей группы люди из Microsoft как раз тогда наняли. Я же в тот момент решил не ехать, так как мне нравилась моя работа здесь. В течение следующего года мои друзья писали мне, как им нравится работать в Microsoft, что для них созданы все необходимые условия и предоставлена интересная работа. Я тогда тоже решил попробовать, отправил резюме и был принят. Это был октябрь 1999 года. В тот момент я попал в группу CLR (Common Language Runtime). Эта группа занималась разработкой ядра .NET. Так уж получилось, что с самого начала вся моя работа была связана с безопасностью. Я занимался криптографическими средствами, да и в CLR я занимался безопасностью.
В группе CLR я проработал 4 года, а затем перешел в группу SWI (Secure Windows Initiative). Это команда людей, которая, по сути, началась с осознания того, что Windows должна стать более безопасной системой. Впоследствии было принято решение о создании группы разработчиков специального программного обеспечения, предназначенного для поиска проблем, связанных с безопасностью. Я стал ее организатором и руководителем. Наш коллектив занимается тем, что разрабатывает средства, помогающие находить уязвимости в программном коде или же тестировать этот код на безопасность, например, проводя моделирование угроз. Фактически мы должны поддерживать SDL (Security Development Lifecycle) - цикл безопасной разработки программного обеспечения.
- Что представляет собой цикл SDL? Каким образом он реализуется в разработках Microsoft?
- Как я уже сказал, SDL представляет собой безопасный цикл разработки программного обеспечения. По сути, это набор лучших методик (best practices) по созданию безопасного ПО. Это набор процессов, которые рассказывают, что же нужно делать, чтобы программное обеспечение было более безопасным. Процесс безопасной разработки делится на семь стадий, а SDL для каждой стадии предоставляет необходимый набор документов, чтобы разработчик правильно подходил к каждой стадии. К примеру, на стадии дизайна производится моделирование угроз. Оно позволяет программистам, которые не являются экспертами, проанализировать систему и закрыть возможные пути для возникновения опасности. На этапе разработки SDL говорит о том, какие инструментальные средства следует использовать. Например, если вы используете компилятор С или С++, SDL говорит, какие функции стоит использовать, а какие не стоит, какие ключи компилятора вам нужны. Ведь существуют такие ключи компилятора, которые как раз и рассчитаны на обеспечение безопасности. В частности, ключ /GS позволяет защититься от ошибки, связанной с переполнением буфера. Есть и средства нахождения проблем безопасности во время тестирования.
Внутри Microsoft SDL обновляется каждые шесть месяцев. Сейчас общедоступной версией является 3.2. Правда, внутри Microsoft она уже в версии 4.
- Можете ли привести конкретный пример реализации SDL в конкретном продукте Microsoft?
- Начнем с обучения. Внутри Microsoft каждому разработчику, тестировщику и менеджеру продукта необходимо раз в год проходить треннинг по безопасности. Более того, если хотя бы один из разработчиков не прошел такой тренинг, продукт не может быть выпущен. Наша группа занимается в том числе и тем, что отслеживает статистику по обучению. Если смотреть на дизайн, то очень большой упор делается на моделирование угроз. Возьмем какой-то конкретный компонент, допустим - файловую систему Windows. Собирается группа, которая включает в себя наших представителей, архитекторов и самих разработчиков. Мы садимся вместе и начинаем процесс моделирования угроз. Рисуется диаграмма потоков данных, где показано, как эти данные перемещаются по системе, что с чем взаимодействует, как работают основные узлы и т.д. Также есть специальные таблицы, которые показывают, какие типы угроз применимы к тем или иным элементам в диаграмме потоков данных. Они фокусируются на этих типах угроз. Существуют и специальные наводящие вопросы. Допустим, если вы храните информацию в файле, то к файлам применимы такие-то типы угроз. Далее от разработчика требуется решение, как будут смягчены возможные типы угроз. Если такой угрозой может быть утечка данных, то ему следует подумать о шифровании. Если речь идет о передаче данных по сети, то можно использовать SSL или IPsec. Затем по результатам составляется модель угроз, которую нужно предоставить центральной группе, чтобы продукт мог увидеть свет.
Наша группа разрабатывает внутренние инструменты, с помощью которых можно удостовериться, что все вышеназванное было сделано.
- На каком этапе разработки нового продукта вступают в действие методики SDL?
- На самом раннем. Еще до того, как архитектура нового продукта начинает обдумываться и формироваться, его разработчики уже думают о его безопасности. В первую очередь разработчики решают, что это за продукт, какие задачи он будет выполнять. И уже на этом этапе они думают о потенциальных угрозах и проблемах безопасности.
- Может ли SDL учесть совершенно новые угрозы, которые ранее никогда не были зафиксированы?
- Ответ можно поделить на две части. Во-первых, когда создается модель угроз, она сначала фокусируется не на конкретных угрозах, а на их типах. Возьмем, к примеру, утечку информации. Сегодня она может быть вызвана переполнением буфера, а завтра ее причиной может оказаться совершенно новый тип вируса. Когда же пытаются закрыть эти угрозы, то смотрят, как правило, на то, что известно в данный момент. Тем не менее, есть два основных принципа, которые позволяют закрыть и будущие угрозы. Первый - это минимизация поверхности атаки, а второй - глубинная защита. Минимизация поверхности атаки состоит в том, что мы измеряем количество возможных точек входа в систему - какие файлы она читает, с какими пользователями она работает и т.д. Минимизация заключается в том, чтобы понять, нужна ли эта точка входа в установках по умолчанию. Допустим, нужно, чтобы с системой могли работать такие-то и такие-то пользователи. Но их число составляет всего один процент. Поэтому лучше по умолчанию выключить эту возможность, а если заказчику она потребуется, то он ее включит. Иными словами, мы стараемся без лишней надобности не оставлять открытыми форточки, чтобы в них не влез злоумышленник.
Вторая концепция - это глубинная защита. Ее еще называют многослойной защитой. Возьмем угрозу утечки информации. От нее могут быть какие-то конкретные методы защиты, но вызвана она может быть тем, что в результате переполнения буфера произошло что-то плохое. Второй уровень защиты помогает предотвратить ошибки переполнения буфера. Компиляторы Microsoft позволяют предотвратить ошибку переполнения буфера с помощью специальных ключей. Если же она все-таки случилась, и какой-то вредоносный код пытается выполняться, в операционной системе есть и более глубокая защита. К примеру, в Vista есть технология ASLR (Address Space Layout Randomization), которая позволяет загружать модули не по постоянным, а по случайным адресам. Это позволяет избежать угрозы от некоторых из эксплойтов, ориентированных именно на встроенный адрес. В результате, даже если ошибка переполнения буфера и произойдет, вредоносный код выполнен не будет.
- Взаимодействует ли Microsoft со сторонними производителями средств разработки, чтобы и они могли реализовать в своих продуктах методики SDL?
- Да, конечно. Набор практик SDL совершенно не зависит от того, на какой платформе ведется разработка. Тот же процесс моделирования угроз можно реализовать в любой среде - хоть Windows, хоть Linux - и на любом наборе инструментальных средств - хоть Visual Studio, хоть Borland. Как правило, в публикациях по SDL подробно описывается, как один и тот же шаг сделать в Visual Studio, gcc, Borland или другом компиляторе.
- Существует расхожее мнение, что проблема с безопасностью кода того или иного продукта часто обусловлена его закрытым статусом. Способно ли открытие кода сделать его более безопасным?
- У всех разное мнение на этот счет. Лично я еще не видел каких-то доказательств в пользу того, что открытие кода делает его более безопасным. Я часто демонстрирую слайд, который отображает количество уязвимостей в операционной системе, обнаруженных в течение первого года после ее выпуска. Windows сравнивается с другими популярными ОС, но мы их специально не называем. Windows XP делалась без SDL, и в ней было найдено 119 уязвимостей, а в Vista, которая делалась уже с использованием SDL, только 66. Если же посмотреть на остальные ОС, некоторые из которых основаны на открытом коде, то там можно увидеть, что уязвимостей на порядок больше. Я лично считаю, что во многих случаях открытый код может быть хуже для безопасности, чем закрытый. Когда разные люди могут вносить в код те или иные изменения, не связанные друг с другом, это может привести лишь к дополнительным проблемам в области безопасности. В то же время, разработчики ПО с закрытым кодом в состоянии обеспечить более строгий контроль над ним. То же самое можно сказать и про обновления. Для закрытого кода их выпускать проще, так как их проще будет протестировать на различных конфигурациях и не создать новых проблем.
Некоторые говорят, что у Microsoft исправление той или иной проблемы вызывает слишком много времени. Сейчас с этим дело лучше обстоит. Тем не менее, это занимает какое-то время, так как патч должен быть протестирован на различных конфигурациях оборудования и в комбинации с самым различным софтом. Ведь корпоративные клиенты устанавливают патч на тысячи машин, и очень важно, чтобы у них ничего не сломалось.
- Сколько сотрудников в Microsoft занимается SDL?
- Я на этот вопрос обычно не даю прямого ответа. Если назовешь какое-то точное количество человек, то один скажет: "как же много, так почему же у них в продуктах все равно попадаются уязвимости", а второй скажет: "как же мало, неудивительно что у них в продуктах столько уязвимостей". Но обычно, когда задают этот вопрос, то пытаются понять объем инвестиций Microsoft в разработку безопасного кода, достаточно ли персонала? По моему мнению, средств инвестируется довольно много, и наша группа достаточно быстро растет - быстрее, чем многие другие подразделения корпорации.
- Как вы взаимодействуете с сообществом сторонних разработчиков в плане обучения их методикам SDL?
- C 2005 года выходят SDL White Papers - публикации, которые находятся в открытом доступе на сайте Microsoft. Затем вышла большая книга в нашем издательстве и несколько статей. Мы активно продвигаем SDL в массы и знаем, что некоторые компании уже начинают с интересом смотреть в сторону этих методик. Кроме того, уже в ноябре мы планируем запустить модель оптимизации SDL. Если помните, раньше выпускались такие модели для оптимизации инфраструктуры, для приложений. Они предоставляли клиенту пошаговую инструкцию: как, например, грамотно выстроить ИТ-инфраструктуру на базе Windows - сколько серверов, сколько клиентов для этого понадобится, как это все настроить, какие программы установить и т.д. Подобное будет написано и про SDL. Будет пошаговая модель внедрения SDL в компании, занимающейся разработкой ПО.
Также будет запущена сеть SDL Pro, в которую войдут девять наших партнеров. Они будут предоставлять консультационные услуги по SDL и услуги по ее внедрению. И, наконец, мы выпустим специальное программное обеспечение для моделирования угроз. Оно будет включать в себя наводящие вопросы, которые помогут разработчикам правильно оценить и смоделировать возможные угрозы, связанные с их продуктом. Любой архитектор или менеджер проекта, даже не являющийся профессионалом в области Security, сможет с его помощью увидеть полную картину. Это будет бесплатный программный инструмент, который можно будет скачать с нашего сайта.
- Каковы ваши впечатления от российских разработчиков, которым вы читали лекции про SDL?
- Судя по вопросам наиболее активных слушателей, к этой теме есть очень большой интерес. Все думают о безопасности, не только в других странах, но и в России. Причем основной процент уязвимостей обнаруживается не в операционных системах, а в приложениях. Дело в том, что операционные системы слишком долго разрабатываются, к ним привлечено всеобщее внимание. А новые приложения появляются каждый день. Кстати, 86 процентов уязвимостей в приложениях приходится на приложения, сделанные компаниями, не входящими в пятерку наиболее крупных разработчиков софта. И только 14 процентов находят в продуктах, выпускаемых первой пятеркой.
Российские компании, которые смотрят в будущее и хотят просуществовать много лет, начинают сейчас очень сильно фокусироваться на безопасности. В этой среде существует некоторый информационный вакуум. Люди знают, что безопасность кода очень важна, но не все знают, что в в связи с этим нужно делать. SDL - это как раз попытка собрать и структурировать информацию, которую накопила Microsoft, в том числе и на основе анализа собственных ошибок. У нас есть цифры, которые подтверждают, что эта методика действительно работает.
