За последние несколько недель мы стали свидетелями нескольких значимых событий, иллюстрирующих подход Apple к вопросам обеспечения безопасности. События эти были как отрицательными, так и положительными. С одной стороны, компания до сих пор не может пропатчить баг в Java, с момента обнаружения которого прошло уже пять месяцев и который был устранен на всех остальных основных платформах, а с другой – недавно Apple взяла на работу Ивана Кристича, разработчика серьезной архитектуры безопасности для платформы OLPC.

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

Учитывая грядущий выход новых версий Mac OS X и операционной системы для iPhone, настал подходящий момент подумать над тем, как Apple могла бы улучшить свою политику в отношении безопасности. Вместо того чтобы фокусироваться на конкретных уязвимостях или огульно критиковать Apple, я предлагаю рассмотреть несколько мер, которые помогли бы компании занять лидирующие позиции в области обеспечения безопасности пользователей на долгосрочный период.

Назначить директора по информационной безопасности и наделить его полномочиями

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

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

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

Внедрить программу безопасной разработки приложений

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

Чтобы справляться с такими вызовами, некоторые поставщики программных продуктов внедрили специальные программы и процессы безопасной разработки (их часто называют "secure software development" или "secure software development lifecycle"). Подобные методики крайне эффективны в уменьшении числа и степени критичности связанных с безопасностью уязвимостей, поэтому они медленно, но верно становятся стандартом разработки в больших компаниях и у крупных разработчиков. Применение политик безопасной разработки позволяет получить дополнительные преимущества от улучшения общего уровня качества программного продукта и уменьшить количество дорогостоящих патчей.

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

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

Организовать группу лиц, ответственных за реагирование на инциденты, связанные с безопасностью

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

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

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

Заняться уязвимостями во встроенных приложениях сторонних разработчиков

Как я уже неоднократно отмечал, самой главной проблемой Apple является своевременный выпуск патчей для сторонних (и по большей части открытых) приложений, встроенных в продукты Apple. За компанией тянется длинный след из вовремя не пропатченных багов, которые на других платформах уже давно пропатчены (в качестве примера здесь можно привести Java, Samba, Apache, DNS и даже собственные разработки Apple в лице WebKit и mDNS).

Такая ситуация прокладывает злоумышленнику не просто путь, а прямое и свободное шоссе к вашему компьютеру. Например, Metasploit теперь способен целенаправленно атаковать Mac OS X, причем полнофункциональные методы нападения для всех платформ встраиваются в эту утилиту спустя лишь часы и дни после выхода патчей.

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

Завершить внедрение технологий защиты от эксплоитов

С выпуском Mac OS X 10.5 Leopard компания Apple начала развертывание набора технологий защиты от эксплоитов. Но даже если она внедрит все перечисленные мною выше меры защиты, это все равно не устранит все уязвимости в ее операционных системах, поскольку дыры будут обнаруживаться в тех приложениях, которые выпущены для Mac и iPhone не фирмой Apple.

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

Как уже поняли в Microsoft, важно внедрять аналогичные элементы контроля в отдельные приложения, а не только в операционные системы, чтобы один-единственный плагин типа Flash или Java не смог разрушить защиту всей системы мер блокировки эксплоитов. Ходят слухи, что ряд таких средств мы увидим уже в грядущей ОС Snow Leopard, что можно назвать положительным сдвигом.

Бесспорно, использовать продукцию Apple сейчас сравнительно безопасно, однако уже появляются первые признаки того, что если компания не усилит работу над архитектурой и политиками безопасности, ее клиенты начнут подвергаться все большему риску. Я написал эту статью не потому, что меня вдруг начала беспокоить безопасность всех семи Mac-ов, которые у меня есть, а потому, что я хочу наслаждаться безопасным общением с системой и в обозримом будущем. Последовав моим светам, Apple могла бы улучшить свою (не всегда заслуженную) репутацию производителя безопасных компьютеров и стать долгосрочным лидером в области компьютерной безопасности.