Досье по информационной безопасности

Обеспечение безопасности на протяжении всего цикла разработки. Преимущество у Майкрософт

Дата: Ноябрь 2006 г.

Автор: Джон Олтсик (Jon Oltsik), старший аналитик

Аннотация. Когда речь заходит о Майкрософт и безопасности, лишь немногие упоминают используемую кор­порацией методику обеспечения безопасности на протяжении всего цикла разработки (Security Development Lifecycle, SDL). Специалисты Enterprise Strategy Group (ESG) считают это досадным умолчанием. На самом деле приверженность Майкрософт методике SDL является свидетельством скрытого лидерства в области безопасности. По мнению ESG, другим независимым поставщикам программного обеспечения следует как можно скорее взять на вооружение модель SDL, а крупные организации должны потребовать, чтобы поставщики технологий к 2008 году создали измеримый и прозрачный процесс SDL, и подчеркнуть, что в противном случае те рискуют потерять заказчиков.

Простейшая формула управления рисками выглядит следующим образом:

угроза + уязвимость = риск

В этом уравнении угроза определяется как «любое естественное или вызванное действиями человека событие, которое может повлечь неблагоприятные либо пагубные последствия», а уязвимость — как «отсутствие либо слабость защиты ресурса, что делает угрозу потенциально более вредоносной или увеличивает размеры ущерба». Угрозы в этой формуле являются относительно постоянной, неизменной величиной. Вполне вероятно, что человеку, который проведет несколько лет во Флориде, доведется пережить ураган. Поскольку угрозы вездесущи и неуправляемы, ключевым фактором обеспечения безопасности является снижение риска. Устранение уязвимостей позволяет снизить риск до приемлемого уровня.

НЕ нашли? Не то? Что вы ищете?

Если применить принципы управления рисками к разработке программного обеспечения, то методика снижения рисков представляется очевидной: достаточно уменьшить количество уязвимых мест в коде и (или) сделать их менее опасными, и уровень риска фактически снизится. На самом деле, незамысловатые заявления типа «пишите более качественный код» на годы превратились в своеобразное заклинание в кругах, связанных с безопасностью. К сожалению, это очевидное решение легче сформулировать, чем реализовать. Почему? Во-первых, разработчикам и независимым поставщикам программного обеспечения следует перестать по-страусиному прятать головы в песок и признать наличие проблемы. Как это ни прискорбно, даже когда это произойдет — а это произойдет, — разработка надежного кода по-прежнему останется труднодостижимой целью по следующим причинам.

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

·  Программистам недостает навыков разработки ПО, ориентированной на безопасность. Даже если группе разработчиков программного обеспечения прикажут строго придерживаться передовых методик обеспечения безопасности, немногие будут знать, с чего начать. Ведущие технические учебные заведения, такие как университет Карнеги-Меллона, Массачусетский технологический институт, Стэнфордский университет и Калифорнийский университет Беркли, либо только начинают предлагать курсы по методам разработки защищенного ПО, либо рассматривают безопасность как один из нескольких элементов, имеющих отношение к «качеству» программного обеспечения. Это означает, что опытный инженер-программист с десятилетним стажем работы не обладает почти никакими знаниями о разработке защищенного ПО.

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

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

Рис. 1. Статистика координационного центра CERT по уязвимостям
программного обеспечения, зарегистрированным в 2000–2006 годах

Корпорация Майкрософт и рождение концепции SDL

Разработка программного обеспечения чем-то похожа на стремление сбросить вес. Кругом полно продуктов, которые, как обещают, принесут огромную пользу, но единственный проверенный способ действительно избавиться от лишних килограммов — изменить поведение, а именно, скорректировать режим питания и увеличить физические нагрузки. Эта истина верна и в отношении разработки защищенного программного обеспечения. Поставщики чудесных средств, возможно, и обещают отличные результаты, но единственно верный способ создать надежный код заключается в том, чтобы встроить безопасность в сам процесс разработки. В условиях все более частых и сложных атак SDL превратился из «полезного» в «совершенно необходимый» процесс.

В то время как все независимые поставщики программного обеспечения лишь на словах признают важность разработки защищенного ПО, корпорация Майкрософт стала бесспорным лидером в этой области. Работу корпорации Майкрософт по обеспечению безопасности в большинстве случаев связывают со знаменитым ныне манифестом «Защищенные информационные системы», разосланным всем служащим Майкрософт по электронной почте в начале 2002 года. На самом деле, совершенствование ориентированного на безопасность процесса к тому времени уже шло полным ходом.

Надежные основы SDL были заложены еще в 1998 году, когда корпорация Майкрософт сформировала рабочую группу внутренней безопасности, в которую вошли отдельные специалисты, работавшие над требованиями к безопасности с различными группами разработки продуктов. В период создания Windows 2000 требования к безопасности были в большей степени встроены в процесс разработки, и родилась инициатива защищенного Windows (Secure Windows Initiative, SWI). Были введены дополнительные проверки проектных решений и кода с точки зрения безопасности, а группа безопасности получила право «приостановить поставку», если продукт, по оценкам, содержал уязвимости, связанные со значительным риском.

В последующие годы совершенствование ориентированных на безопасность процессов разработки продолжилось: повышенное внимание стало уделяться предварительному обучению, анализу уязвимых мест, снижению уязвимости и безопасным «по умолчанию» конфигурациям.

С 2000 по 2004 год новые выпуски продуктов проходили все более сложную комплексную проверку безопасности. Качество безопасности неуклонно повышалось, однако комплексная проверка безопасности по-прежнему основывалась на множестве специально создаваемых для каждого случая процессов, управляемых все большим числом экспертов. С учетом растущей потребности в надежном коде, развитие методики SDL получило самый сильный импульс, когда высшее руководство Майкрософт решило придать разработке защищенного программного обеспечения официальный статус с помощью формализованного определения SDL. Архитекторы SDL Майкл Говард (Michael Howard) и Стив Липнер (Steve Lipner) считают, что именно выражение исполнительным руководством корпорации своей приверженности данной концепции стало переломным моментом в превращении SDL из дополнения к процессу разработки в основополагающий компонент культуры Майкрософт. С этого времени все программное обеспечение, применяющееся в коммерческой деятельности, содержащее личные данные или конфиденциальную информацию либо использующееся в Интернете, разра­батывается в соответствии с процессом SDL.

Описание SDL простым языком

Процесс SDL состоит из 13 этапов (с 0 по 12 включительно), которые начинаются с обучения и информи­рования и завершаются практическим реагированием на нарушения безопасности. Подробный анализ этих этапов не входит в задачи данного документа, но, по мнению ESG, упомянутые 13 этапов можно суммировать с помощью упрощенной модели цикла разработки, представленной ниже (см. рис. 2).

Рис. 2. Упрощенная схема процесса SDL

1. Подготовка. Этапы 0–5 включают четко определенные процессы обучения, изучения рекомендованных методов, анализа рисков и создания предназначенных для заказчиков документов, средств и процедур по обеспечению безопасности. Таким образом, назначение SDL — побудить разработчиков продумать вопросы безопасности с точки зрения разработки проекта, планирования и потребностей заказчиков. Цель заключается в эффективной предварительной подготовке, исключении неожиданностей и распростра­нении безопасности на все выходные продукты для заказчиков, а не только на двоичные файлы.

2. Разработка. На этапах 6–7 отрабатывается методика создания надежного кода и тестирования надежности. Создание надежного кода зависит от предыдущих этапов, включая обучение и рекомендации. В методике SDL также подчеркивается необходимость замены известных опасных функциональных возможностей более безопасными вариантами. Тестирование надежности — особенно загадочная тема. В SDL делается акцент на тестирование поведения приложений и протоколов с помощью искаженных данных и пакетов, а также на проверку устойчивости к внешним атакам. Кроме того, на этом этапе важно повторно проверить проектное решение продукта и уязвимые места, чтобы ограничить потенциальную уязвимость.

3. Проверка. На этапах 8–9 проводится комплексная проверка безопасности и заключительная проверка. Именно на этих этапах все, включая код, документацию и все вехи процесса SDL, проверяется с точки зрения безопасности. Если разработка велась в строгом соответствии с методикой SDL, заключительная проверка безопасности продукта должна быть относительно простой, поскольку известные уязвимости связаны с низкой степенью опасности, а дальнейшие риски тщательно проанализированы.

4. Мониторинг и реагирование. Даже при строжайшем соблюдении процедур SDL выявление новых уязвимостей в системе безопасности неизбежно. В целях их устранения на этапах 10–12 процесса SDL основное внимание уделяется планированию реагирования, выпуску продукта и практическому реагированию на нарушения безопасности. На этих этапах чрезвычайно важно анализировать данные, поступающие от пользователей, быстро тестировать возможные неполадки и готовить меры противо­действия на различных уровнях. Технические меры противодействия должны поддерживаться надежной связью, чтобы заказчики ясно понимали и оценивали свои риски и правильно на них реагировали.

Несмотря на характерную для нее жесткость требований, методология SDL остается динамичным развиваю­щимся процессом, который подвергается постоянным пересмотрам в целях совершенствования. Для внесения в процесс усовершенствований и учета новых угроз безопасности корпорация Майкрософт дважды в год делает SDL доступным для анализа и изменения. По мнению Майкрософт, нацеленность SDL на постоянное совершенствование, подобно стандартам Six Sigma и ISO, является важнейшим условием успеха этой методики и в дальнейшем.

Затраты и выгоды SDL

Корпорация Майкрософт не скрывает, что процесс SDL не является легким или свободным от затрат. На самом деле, по оценкам Майкла Говарда и Стива Липнера, соблюдение методики SDL может увеличить длительность цикла проектирования продукта, содержащего значительный объем кода из прежних версий, на 15%–20%.

При прочих равных условиях, стоит ли оно того? Майкрософт считает, что стоит. Говард и Липнер с энтузиазмом ссылаются на такие показатели, как 50-процентное снижение числа уязвимостей во всех программных продуктах и на SQL Server 5.0, который прошел процесс SDL с начала до конца. Главный специалист по SDL Майкл Говард считает SQL Server образцом успеха методики. На момент написания этого материала непосредственно в ядре СУБД SQL Server не выявлено ни одного уязвимого с точки зрения безопасности места в течение уже более трех лет. Предстоящий выпуск Vista станет первой версией Windows, которая пройдет процесс SDL, и Майкрософт ожидает подобных же результатов. Конечно, в Vista, как и в любом другом сложном программном продукте, будут уязвимые места. Но Майкрософт считает, что в течение нескольких лет Vista продемонстрирует уменьшение общего числа уязвимостей по сравнению с прежними версиями Windows, а также снижение степени серьезности выявленных уязвимостей. В целом, безопасность продуктов Майкрософт будет становиться надежнее и в дальнейшим, по мере того как другие продукты пройдут через процедуру SDL впервые и затем будут совершенствоваться с каждым последующим прохождением.

Методика разработки защищенного программного обеспечения полностью отвечает поговорке «легче болезнь предупредить, чем потом ее лечить». В нескольких академических исследованиях сделаны следующие выводы.

·  Один час работы по контролю качества программного обеспечения позволяет сэкономить от 3 до 10 часов работы по исправлению недостатков после выпуска ПО.

·  Если дефект в требованиях к программному обеспечению выявлен только на этапе разработки или по ее завершении, то его исправление обойдется в 50–200 раз дороже.

·  Если дефект, который не был обнаружен и исправлен при проверке кода, выявлен только на этапе разработки или по ее завершении, то его исправление обойдется в 10–100 раз дороже.

Корпорация Майкрософт также указывает на сокращение затрат, обусловленное SDL в соответствии с эффектом умножения. Куда дешевле исправить или предотвратить возникновение уязвимости в рамках цикла разработки, нежели устанавливать исправления на более чем 100 миллионов настольных ПК, находящихся у пользователей!

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

Итоги

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

Усилия Майкрософт заслуживают всяческой похвалы, но Редмонд не является единственным поставщиком на рынке программного обеспечения. Отсюда вопрос: насколько серьезно другие поставщики программного обеспечения и технологические компании относятся к совершенствованию безопасности своего кода? По мнению ESG, возможен только один ответ на этот вопрос — «недостаточно».

В целях стимулирования усилий по повышению безопасности программного обеспечения в масштабе всей отрасли крупные организации должны потребовать, чтобы их поставщики технологий приняли на вооружение методику SDL, аналогичную той, что используется корпорацией Майкрософт. (Следует отметить, что текущая спецификация PCI — версия 1.1 — рекомендует проверки безопасности кода в качестве передового метода и в 2008 году сделает их обязательным требованием.) Процесс SDL должен быть документирован, а крупные заказчики должны иметь возможность оценить процесс и даже провести аудит результатов.

Рассматривая спецификацию PCI как эталон, ESG считает, что к 2008 году все адресованные исполнителям корпоративные запросы информации и запросы предложений должны содержать требование к поставщикам предоставить сведения о процессах SDL и соответствующие показатели. А тем, кто не желает или не в состоянии сделать этого, следует вежливо указать на дверь.

Все товарные знаки являются собственностью соответствующих владельцев. Информация, содержащаяся в этой публикации, получена из источников, которые Enterprise Strategy Group (ESG) считает надежными, однако ESG не гарантирует ее достоверность. Данная публикация может содержать мнения ESG, которые могут со временем изменяться. Авторские права на эту публикацию принадлежат Enterprise Strategy Group, Inc.; публикация предназначена исключительно для использования Подписчиками или лицами, которые приобрели ее непосредственно у ESG. Любое воспроизведение или повторное распространение данной публикации, целиком или по частям, будь то в печатном или электронном формате либо в каком-либо ином виде, лицам, не имеющим права на ее получение, без явно выраженного согласия Enterprise Strategy Group, Inc. является нарушением законодательства США об авторском праве и повлечет за собой судебный иск о взыскании убытков в гражданском порядке и, если это предусмотрено, уголовное преследование. По всем возникающим вопросам обращайтесь в отдел по связям с клиентами ESG по