Oracle совершенствует тестирование кода

Компания переходит к большей открытости в вопросах безопасности и ускоряет информирование клиентов о заплатах

Oracle все это надоело. В то время как корпорация Microsoft и ее разработчики цитировали конкретные пункты своего руководства по созданию ПО "Безопасный цикл разработки" (Security Development Lifecycle), которое представляет собой набор описаний процессов определения общего дизайна, разработки, тестирования и развертывания, позволяющих создавать надежное ПО, компания Oracle - лидер в сфере баз данных - хранила молчание относительно собственных инициатив в области разработки надежных программ. И это несмотря на то что ее клиенты неоднократно говорили о низком качестве выпускаемых Oracle исправлений и об уязвимостях в ее ПО, которые слишком долго не устраняются.

Джон Хейман: “Совершенствование

системы информирования

пользователей является ключевым

элементом нового подхода Oracle

к обеспечению безопасности”

"Отчасти это обусловлено тем, что многие исправления Oracle напрямую связаны с низким качеством программного кода", - отметил Ден Даунинг, вице-президент по тестированию компании Mentora Group, которая предоставляет услуги в области тестирования бизнес-приложений, хостинга и внешнего управления (г. Атланта).

Крупные клиенты могут радоваться, что их базы данных Oracle надежно защищены брандмауэрами. "Я занимаюсь исправлением ошибок в системах этой компании 10 лет, - сказал Говард Фосдик, бывший президент организации пользователей баз данных Midwest Database Users Group. - В общем и целом мое мнение таково, что Oracle всегда хорошо делала свое дело: в разумные сроки, с разумной тщательностью".

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

Oracle переходит к открытости

Недавняя история Oracle (см. ниже) знает примеры, когда исправления не устанавливались должным образом и когда выпускались исправления для исправления исправлений, а затем новые исправления для устранения проблем безопасности, образовавшихся в результате кумулятивного эффекта.

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

Одним из членов команды, отвечающей за решение данных проблем, является Джон Хейман, директор Oracle по управлению программой безопасности.

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

Во время организованной для eWeek и продолжавшейся целый день экскурсии по штаб-квартире Oracle в г. Редвуд-Шорзе, шт. Калифорния, с целью ознакомления с работой корпорации по обеспечению безопасности г-н Хейман поведал, что Oracle переходит к более интенсивному тестированию своих программ, и кратко обрисовал, как это делается. В декабре компания объявила, что будет использовать технологию статичного анализа кода, разработанную фирмой Fortify Software (г. Пало-Альто, шт. Калифорния) для поиска ошибок в программах на языках Cи, C++, PL/SQL и Java в рамках акции, направленной на совершенствование методов обнаружения пробелов в безопасности. Эта технология применима в процессе разработки продукта, что позволяет не "латать дыры" после его выпуска. Oracle сотрудничает с Fortify на протяжении полутора лет.

В январе нынешнего года созданный в Fortify инструмент был установлен для работы со всеми продуктами Oracle. Он должен выдерживать мощную нагрузку. Только СУБД Oracle насчитывает от 40 до 50 млн. строк кода. Инструмент должен масштабироваться, чтобы выдавать результаты в разумных временных пределах, и быть способным работать на параллельных машинах.

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

Oracle также изучает возможности автоматического тестирования по принципу "черного ящика"; в ходе этой операции контроль на входе и выходе позволяет обнаружить выполнение команд на языке SQL. Корпорация определила потенциального поставщика и готовится к повсеместному использованию его продукта. Однако назвать этого поставщика и уточнить сроки г-н Хейман отказался.

Выявление ошибок

Это не первый случай, когда Oracle предпринимает широкомасштабное тестирование программ. Впервые компания произвела оценку безопасности в 1990 г., чтобы пройти проверку на соответствие требованиям министерства обороны TCSEC (Trusted Computer System Evaluation Criteria - критерии оценки надежности компьютерных систем), известным также под названием "Оранжевая книга", и принятым в Западной Европе ITSEC (Information Technology Security Evaluation Cri-teria - критерии оценки безопасности информационной технологии). Эти испытания проводились еще до расцвета Интернета и Web-приложений, сделавших возможным внедрение языка SQL и других "вредных" средств в серверные базы данных.

По словам Дункана Харриса, старшего директора Oracle по обеспечению безопасности, когда Oracle 7 впервые тестировалась на соответствие правительственным требованиям по безопасности в Европе, была обнаружена одна "дыра".

До 1 декабря 1999 г. было найдено лишь еще одно уязвимое место в системе безопасности. Его устранили тем же способом, что и первое, - записав исправление на магнитные ленты и компакт-диски, которые распространялись среди пострадавших клиентов.

В феврале 2001 г. Oracle выявила девять ошибок. К сентябрю 2001-го их число возросло до семнадцати. К декабрю 2002 г. оно увеличилось до 72. Потом наступил август 2004 г., когда было выпущено злополучное исправление Alert 68 - первое, содержавшее несколько исправлений для нескольких уязвимостей.

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

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

Тем не менее г-н Даунинг из компании Mentora считает, что среди клиентов сохраняется "высокий уровень скептицизма" относительно качества новых исправлений или пакетов обновлений (Family Packs) - наборов выпущенных ранее исправлений. В первую очередь это связано с Alert 68 - набором заплат, известным своим низким качеством. "Все шире распространяется мнение, что вы должны на свой страх и риск устанавливать эти заплаты и пакеты обновлений, не прошедшие настоящего тестирования", - подчеркнул г-н Даунинг.

Недостаточная информация об исправлениях, вошедших в Alert 68, лишь усугубила технические проблемы. Специалист по безопасности баз данных Аарон Ньюмен, главный технолог и один из основателей компании Application Security, говорит, что сразу после выпуска Alert 68 несколько клиентов звонили ему и "очень просили предоставить информацию", нужно ли им использовать эти заплаты и с чем именно связаны проблемы уязвимости.

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

Хотя данный "не-червь" явился результатом ненадежной конфигурации учетных записей Listener - серверного процесса, обеспечивающего базовый сетевой доступ к СУБД Oracle для клиентов, серверов приложений и других баз данных, а не результатом ошибки в программе, в день визита сотрудников eWeek корпорация торопилась предоставить клиентам информацию относительно надлежащей конфигурации, позволяющей "залатать дыры".

"В настоящее время мы более гибко откликаемся на обращения пользователей, - говорит г-н Хейман. - У нас имеется новая процедура реагирования на угрозы безопасности, специально ориентированная на это. Мы получили отклики в связи с первоначальной рассылкой Voyager. Так что сегодня мы приступаем к рассылке электронных сообщений по поводу повторного появления Voyager. Теперь мы имеем возможность быстро распространить эту информацию".

Проблема в том, что быстрота ведет к снижению качества. Иногда Oracle должна производить проверки, которые гарантировали бы, что даже блокировка определенного компонента не нарушит работу выпущенного 10 лет назад варианта поддерживаемой версии.

А по мере того как корпорация интегрирует ПО приобретенных ею компаний, например PeopleSoft, продукты Oracle становятся более сложными. И кроме того, существует проект Fusion, который либо избавит корпорацию от прежних проблем, поскольку она начинает работать с принципиально иной архитектурой, либо приведет к появлению дополнительных в связи с введением нового кода.

Глубинные причины

Как Oracle удастся сохранить контроль над всем кодом, если она работает с приобретенными продуктами и целиком поглощена проектом Fusion?

Одним из направлений, в котором она начала работу, является анализ глубинных причин возникновения уязвимостей. "Если появляется ошибка в системе безопасности, мы ставим такие вопросы: почему произошла эта ошибка? может быть, стандарты были нечетко сформулированы? проводилось ли обучение в нужном объеме? данная ошибка представляет собой единственное проявление чего-то или носит систематический характер?" - сказал г-н Хейман.

В конце концов, по его мнению, речь идет о дизайне ПО. "В сущности, это в такой же мере искусство, в какой и наука", - резюмировал г-н Хейман.