Crypto-Gram 15 февраля 2002 года

Микрософт и "вычисления, заслуживающие доверия"

Оценка Микрософт

Crypto-Gram перепечатывает

Новости

Новости Counterpane

"Небьющиеся" базы данных Oracle

Конец журнала 15.02.02

На первую страницу

 

Оценка Microsoft

В прошлом месяце Билл Гейтс издал по компании служебную записку, определяющую новое стратегическое направление для Microsoft. Сравнивая ее с изменениями, когда Компания захватила Internet, Гейтс определяет защиту, как высший приоритет Microsoft. Фокусируя на том, что он назвал "Вычисления, заслуживающие доверия", Гейтс планирует преобразовывать Microsoft в компанию, которая производит программное обеспечение, которое является доступным, надежным, и безопасным. "Мы должны перевести промышленность на новый уровень надежности в обработке" - написал Билл Гейтс в служебной записке 15 января 2002.

Доверие это не то, что может быть выдано; это должно быть заработано. И надежность является достойной целью при обработке. Но в отличие от выполнения цели или списка характеристик, прогресс в этом отношении трудно измерить. Как вы можете определить, что одна часть программного обеспечения более безопасная, чем другая? Или определить, что в одном случае целостность данных лучше, чем в другом? Или для данной задачи определить, что менее вероятно содержание в ней необнаруженных уязвимых мест? Как нам узнать это, что Microsoft действительно принял обязательство о безопасности, или это просто заявление для прессы и публика? Это не так же легко, как проверить точность часов; проблемы безопасности часто не проявляются в опытной эксплуатации.

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

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

Если мы можем превратить наши рекомендации в единственную парадигму, это дает нам простоту. Сложность - наихудший спутник безопасности, и системы, загруженные большим числом характеристик, возможностей, и вариантов выбора, значительно менее безопасны, чем простые системы, которые делают несколько вещей надежно. Ясно, Windows всегда была сложной операционной системой. Но есть вещи у Microsoft, которые сделаны так, что они просты и более безопасны. Microsoft должен направить своих программистов на проектирование сразу же безопасного программного обеспечения в новых продуктах.

  1. Разделение пути Data/Control

"Модель безопасности должна быть легкой для разработчиков, чтобы понимать и строить на ней приложения" - отметил Билл Гейтса в записке по безопасности 15 января 2002.

Он прав. И одной из самых простых, прочных, и безопасных моделей является осуществление жесткого разделение данных и кода. Смешение данных и кода ответственно за очень многие проблемы безопасности, и Microsoft был самый злостный правонарушитель Internet. Имеется один пример: Первоначально, электронная почта была только текстовая, и вирусы в электронной почте были невозможны. Microsoft изменил это, при наличии клиентуры почта автоматически выполняет команды, внедренные в e-mail. Это проложило путь к электронной почте вирусам, подобным Melissa и LoveBug, и это автоматически распространялось людьми в записных книжках жертв. Microsoft должен полностью изменить ущерб защиты, удаляя эти функциональные возможности для клиентуры электронной почты и многое другое из программ. Это твердое разделение данных от кода должно примениться ко всем программам.

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

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

Офис: Макроопределения не должны хранится в документах Офиса. Макроопределения должны храниться отдельно, как шаблоны, которые не должны быть запускаемыми. Программы должны обеспечивать визуальный интерфейс, который используется потребителем, и который использует макроопределения. Но должны быть ограничения, которые не должны быть корпоративным макроопределениями.

Internet Explorer: IE должен поддерживать полное разделение данных и управления. Java и JavaScript должны быть модифицированы, так чтобы они не могли использовать внешние программы на произвольных путях. ActiveX должен устранить все элементы управления, которые выделены в "сейф для описания".

E-mail: приложения E-mail не должны поддерживать создание сценария. (По крайней мере, они должны прекратить поддерживать его по умолчанию). Сценарии E-mail должны быть приложены как отдельное добавление MIME (набор стандартов для передачи мультимедийной информации посредством электронной почты). Должны иметься ограничения на макрокоманды, которые допускаются общим отделом информации.

.NET: .NET должен иметь ясное указание на то, как он может действовать и как не может. Общество узнало много о мобильном Java коде, используемым для безопасности. Мобильный код очень опасен. Для мобильного кода, чтобы сохраняться, должна быть переработана безопасность, как первичная характеристика.

Реализация Microsoft SOAP (Sunflower Oil Assistance Program), протокола, просматривающего HTTP так, чтобы обойти брандмауэр (аппаратно-программные средства межсетевой защиты), должна быть убрана. Согласно документация Microsoft: "Поскольку SOAP используется HTTP как транспортный механизм, и наилучшие брандмауэре (firewall) позволяют HTTP передавать через них, Вы не будете иметь проблемы, вводящие конечные точки SOAP или стороны firewall". Это точно такая характеристика выше настроенной безопасности, которую нужно использовать. Это может быть, что SOAP предлагает механизмы достаточного обеспечения, соответствующего разделения кода и данных. Тем не менее, Microsoft продвигает это для своей исключительной безопасности.

II. Встроенные в конфигурации "Наши изделия должны подчеркнуть право защиты блока" - из записки Гейтса.

Программное обеспечение Microsoft, по умолчанию, устанавливается с большим числом характеристик, чем это нужно потребителям или хотелось бы им иметь. Это делает программное обеспечение более уязвимым, чем необходимо. Есть много примеров этого. Последний из них, это универсальный разъем Plug-and-Play, который работает, даже если Вы не знаете, что UPnP делает, или независимо от Вас и даже, если Вы не используете его. Разъем SuperCookie работает в Windows даже, если бы Вы не используете WMP. Красный код успешно использует IIS установки, даже в установках Windows, которые не используются в качестве Web сервера.

К тому же, характеристики должны быть устанавливаемыми поодиночке. В UNIX, например, сервер Web и ftp сервер разные, и должны быть установлены отдельно. С IIS, устанавливающим Web сервер, не только устанавливает Web сервер, но также и ftp сервер, и сервер, производящий бессистемную разведку, и Билл сам, вероятно, не знает, что еще.

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

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

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

III. Разделение протоколов и программ

"Поскольку программное обеспечение стало более комплексным, взаимозависимым и связанным, репутация нашей компании в свою очередь стала более уязвимой", отмечено в записке.

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

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

IV. Построение безопасного программного обеспечения

"Теперь, когда мы сталкиваемся с выбором между дополнением характеристик и разрешением безопасности, нам нужно выбирать безопасность". – Из записки Гейтса.

Коммерческое программное обеспечение полно ошибок, и некоторые из уязвимых мест безопасности обеспечиваются этими ошибками. Это не извинение Microsoft с его апатией к безопасности; это просто утверждение факта. Эти ошибки вызваны плохими техническими требованиями на программное обеспечение, проектом, и реализацией. Большинство связано с разделением данных/команды, с конфигурацией по умолчанию, отдельным программным обеспечением для отдельных протоколов, и приводит к эффекту снижения безопасности. Результаты программных ошибок уменьшают сумму программного обеспечения в компьютере. Тем не менее, там все еще много программного обеспечения на любом компьютере и программное обеспечение должно быть упругим, чтобы сдерживать атаки. Это означает то, что программное обеспечение легко не ломается, когда оно атаковано. И если это делает прерывание, система в целом не разваливается. Сегодня мы можем беспокоиться, что единственный дефект в Windows делает сервер полностью небезопасным, или единственный дефект в IIS поставит все данные в .NET под вопрос. Сегодня программное обеспечение Microsoft хрупкое; а должно быть упругим.

Если Microsoft может делать значительное, чтобы сделать свое программное обеспечением более упругим, наши рекомендации могли быть продолжены на многие страницы. Но, вообще говоря, определенные характеристики более хрупкие, чем другие. Мы рекомендуем следующее:

Microsoft должен отменить все планы автоматической программной коррекции через Internet, пока они не смогут делать это надежно и еще раз надежно. Сегодня есть также много проблем с коррекцией и корректорами, чтобы позволять им производить это без знания потребителя, и слишком много проблем с аутентификацией, чтобы предохраняться от злонамеренно использования возможности атаковать системы.

Microsoft должен устранить обслуживание всех централизованных баз данных клиента на своем .NET. Эти базы данных слишком опасные, чтобы держать их на одном месте; последствия нарушения безопасности слишком большие.

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

Сегодня слишком много компонентов сервера Microsoft запускают как Администратор. Когда услуга выполняется как Администратор, она - значительно легче для недостатков безопасности, чтобы результаты в машине полностью компенсировались. В UNIX, серверы часто разработаны, чтобы запускаться как нормальный потребитель. Они должны быть также встроенной конфигурацией для серверов Microsoft.

Все другое, представляется, Microsoft должно быть оценено с точки зрения эластичности. Т.е. слишком рискованное должно быть удалено, пока оно не может быть перезаписано.

V. Прозрачность и возможность проверки

"Если есть разные пути, мы можем лучше защитить важные данные и минимизировать простые, мы должны сфокусироваться на этом". - Из записки Гейтса.

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

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

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

VI. Авансовая публикация протоколов и проектов

"Есть много изменений, которые Microsoft нужно делать как компании, чтобы гарантировать и обеспечивать доверие клиентов на каждом уровне пути, при котором мы разрабатываем программное обеспечение, в поддержку мер для на нашей практики деловых отношений". - Из записки Гейтса.

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

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

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

VII. Включение общества

"Компенсационные планы инженеров Microsoft, как, например, премии, также будут связаны для обеспечения этих продуктов". –

Статья Гейтса, 15 января 2002.

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

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

Вывод

"В конечном счете, наше программное обеспечение должно быть коренным образом безопасным для клиентов, чтобы они никогда даже не заботились об этом". - Из записки Гейтса.

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

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

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

Забавные комментарии:

<http://slashdot.org/comments.pl?sid=26890&cid=2901270>
<http://slashdot.org/comments.pl?sid=26890&cid=2901649>

Этот очерк был написан Adam Shostack. Комментарии были подготовены Steve Bellovin, Jon Callas, Vrispan Cowan, Greg Guerin, Paul Lalonde, Gary McGraw, David Wagner, и Elizabeth Zwicky. Он первоначально оказался в Security Focus:

<http://www.securityfocus.com/news/315>

 

Авторское право © 2002 Counterpane Internet Security, Inc.

Русский материал Малютина А., редакция Малютиной Н.М.

К началу
Сайт управляется системой uCoz