WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     || 2 | 3 | 4 | 5 |   ...   | 12 |
-- [ Страница 1 ] --

Michael Howard David LeBlank WRITING SECURE CODE Second Edition Microsoft Press

Майкл Ховард Дэвид Лебланк ЗАЩИЩЕННЫЙ код 2-е издание, исправленное Москва 2004 УССШ РЕДАКЦИЯ УДК 004.45 ББК 32.973.26-018.2 Х68 Ховард М., Лебланк Д.

Х68 Защищенный код: Пер. с англ, — 2-е изд., испр. М.: Издательско-тор говый дом «Русская Редакция», 2004. — 704 стр.: ил.

ISBN 5-7502-0238-0 В этой книге разработчики найдут практические советы и рекомендации по защите создаваемых приложений на всех этапах процесса создания ПО — от про ектирования безопасных приложений и до тестирования для выявления брешей в готовой программе и создания безопасной документации и сообщений об ошибках. Здесь рассказывается о моделировании опасностей, планировании про цесса разработки защищенных приложений, проблемах локализации и связан ных с ней опасностях, недостатках файловых систем, поддержке конфиденциаль ности в приложениях и безопасной установке приложений. Авторы иллюстриру ют свой рассказ примерами программ на самых разных языках — от Си до Perl.

Издание обогащено знанием, полученным авторами в процессе реализации Win dows Security Push — инициативы по укреплению защиты продуктов Microsoft.

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

Книга состоит из 24 глав, 5 приложений, библиографического списка с анно тациями и предметного указателя.

УДК 004. ББК 32.973.26-018. Подготовлено к изданию по лицензионному договору с Microsoft Corporation, Редмонд, Вашинг тон, США.

Active Directory, ActiveX, Autbenticode, Hotmail, JScript, Microsoft, Microsoft Press, MSDN, MS-DOS, Visual Basic. Visual C++, Visual Studio, Win32. Windows, и Windows NT являются товарными знака ми или охраняемыми товарными знаками корпорации Microsoft в США и/или других странах. Все другие товарные знаки являются собственностью соответствующих фирм.

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

© Оригинальное издание на английском языке, Microsoft Corporation, © Перевод на русский язык, Microsoft Corporation, 2003- [SBN 0-7356-1722-8 (англ.) © Оформление и подготовка к изданию, шдательско TSBN 5-7502-0238-0 торговый дом «Русская Редакция*, 2003- Оглавление Введение XX Кому адресована эта книга XXI Структура книги XX (I Загрузка и установка примеров приложений XX [I Системные требования XXII Техническая поддержка XXI [I Благодарности XXIII ЧАСТЬ I БЕЗОПАСНОСТЬ ПРИЛОЖЕНИЙ СЕГОДНЯ Глава 1 Необходимость защиты систем Приложения в «дикой» Web-среде Необходимость доверительных вычислений «Танцуют все!* б Тактичные методы пропаганды идей безопасности Запрещенные приемы Некоторые методы насаждения идей безопасности Убедите начальника обратиться к сотрудникам с заявлением на тему безопасности Возьмите в штат поборника безопасности Правила боя Правило №1: защищающемуся приходится охранять все слабые места, а нападающему достаточно выбрать одно из них Правило №2: защищающийся готовится отразить известные атаки.

а нападающий может разработать новые методы взлома Правило № 3: оборону следует держать постоянно, удар же возможен когда угодно Правило №4: защищающему приходится соблюдать правила, а нападающему не возбраняется вести «грязную игру* IS Резюме... VI Оглавление Глава 2 Активный подход к безопасности при разработке приложений Совершенствование процессов Необходимость обучения Отношение сотрудников к обязательному обучению Непрерывность обучения Развитие науки о безопасности Образование позволяет избавиться от заблуждения, что «лишняя пара глаз — всегда лучше» А теперь доказательства! 2б Проектирование Беседуйте с потенциальными сотрудниками Определите цели защиты продукта Рассматривайте защиту как неотделимую функцию программы Отведите на обеспечение безопасности достаточно времени Моделируйте опасности, грозящие системе С самого начала запланируйте процедуру удаления функций, оказавшихся небезопасными Определите допустимое число ошибок Предусмотрите проверку группой по безопасности Разработка Очень осторожно предоставляйте права на внесение исправлений Перепроверяйте внесенные исправления Зб Создайте руководство по созданию безопасного кода Учитесь на предыдущих ошибках Поручите анализ безопасности приглашенным специалистам Разверните кампанию по безопасности Не утоните в потоке обнаруженных ошибок защиты Следите за уровнем ошибок Никаких неожиданностей и «пасхальных яиц»! Тестирование Поставка и сопровождение -. Как узнать, что продукт готов Обратная связь Ответственность Резюме Глава 3 Принципы безопасности, которые следует взять на вооружение Принцип SD': безопасно согласно проекту, по умолчанию и при развертывании.... Безопасно согласно проекту Безопасно по умолчанию Безопасно при развертывании Принципы безопасности Учитесь на ошибках.... Оглавление VII Уменьшайте «площадь» приложения, уязвимую для нападений Назначайте безопасные параметры в конфигурации по умолчанию Защищайте все уровни Используйте наименьшие привилегии Будьте готовы к проблемам с обратной совместимостью Принимайте как аксиому, что внешние системы не защищены по определению Разработайте план действий на случай сбоев и отказов Предусмотрите безопасный сбой Помните, что возможности подсистемы безопасности — это не то же самое, что безопасные возможности системы Не стройте систему защиты на ограничении информации о приложении.... Разделяйте код и данные Корректно исправляйте ошибки в защите Резюме Глава 4 Моделирование опасностей Моделирование опасностей как средство проектирования защищенных приложений Создание группы моделирования опасностей Разложение программы на составляющие Определение опасностей, грозящих системе Распределение опасностей по мере убывания их серьезности Реакция на опасность Отбор методов для предотвращения опасности Методы защиты Аутентификация Авторизация Технологии защиты от несанкционированного доступа и обеспечение конфиденциальности Защищайте секретные данные, а лучше вообще не храните их Шифрование, хеши, МАС-коды и цифровые подписи Аудит Фильтрация, управление входящими запросами и качество обслуживания.... Минимальные привилегии Устранение опасностей, грозящих приложению расчета зарплаты Основные опасности и методы борьбы с ними Резюме ЧАСТЬ II МЕТОДЫ БЕЗОПАСНОГО КОДИРОВАНИЯ Глава 5 Враг №1: переполнение буфера 1С В Переполнение стека Переполнение кучи Оглавление VIII Ошибки индексации массива Ошибки в строках форматирования Несовпадение размеров буфера при использовании Unicode и ANSI Пример ошибки, связанной с Unicode Предотвращение переполнения буфера Безопасная обработка строк Пара слов об осторожности при работе со строковыми функциями Параметр /GS компилятора Visual C++.NET Резюме Глава б Выбор механизма управления доступом Почему списки ACL так важны Раздел не «по теме»: исправление кода доступа к реестру Из чего состоит ACL Как выбрать оптимальный ACL Эффективные запрещающие АСЕ-записи Создание ACL Создание ACL в Windows NT 4 Создание ACL в Windows 2000 Создание ACL средствами Active Template Library Как правильно упорядочить АСЕ-записи Безопасность при использовании SID сервера терминалов и удаленного рабочего стола Нулевая DACL и другие опасные типы АСЕ Нулевая DACL и аудит 1б Опасные типы АСЕ Что делать, если нельзя изменить нулевую DACL Другие механизмы управления доступом Роли в.NET Framework Роли в СОМ+ IP-ограничения Триггеры и разрешения сервера SQL Server Пример приложения для поликлиники Важное замечание по поводу механизмов управления доступом Резюме Глава 7 Принцип минимальных привилегий Ущерб от вредоносного ПО Вирусы и троянцы Изменение страниц Web-сайтов Краткий экскурс в управление доступом Коротко о привилегиях Привилегия SeBackupPrivilege Привилегия SeRestorePrivilege Оглавление IX Привилегия SeDebugPrivilege Привилегия SeTcbPrivilege Привилегии SeAssignPrimaryTokenPrivilege и SelncreaseQuota Privilege Привилегия SeLoadDriverPrivilege Привилегия SeRemoceShutdownPrivilege 1- Привилегия SeTakeOwnershipPrivilege Несколько слов о маркерах Как взаимодействуют маркеры, привилегии, SID, ACL и процессы Идентификаторы SID и травление доступом, а также привилегии и их проверка Три аргумента в пользу назначения приложению высоких привилегий Проблемы с ACL 1 - Проблемы с привилегиями Н Использование секретов LSA 1 ' Решение проблем, возникающих из-за предоставления высоких привилегий 1Ю Решение проблемы ACL 1[) Решение проблем с привилегиями Решение проблем с LSA 1 ' Определение оптимального набора привилегий 1 •.) Этап 1: выясните, какие ресурсы нужны приложению Этап 2: выясните, какими системными API-функциями пользуется приложение Этап 3: определите, какая требуется учетная запись Этап 4: исследуйте содержимое маркера Этап 5: выясните необходимость всех привилегий и SID-идентификаторов.... Этап 6: внесите изменения в маркер Учетные записи непривилегированных служб в Windows XP/.NET Server 2003 Привилегия олицетворения в Windows.NET Server 2003 Отладка ошибок, возникающих из-за ограничения привилегий Резюме Глава 8 Подводные камни криптографии «Слабые» случайные числа Проблема с функцией rand Случайные числа криптографического качества в Win32 Случайные числа криптографического качества в управляемом коде 2 Случайные чиста криптографического качества на Web-страницах Создание криптографических ключей на основе пароля Оценка эффективной длины пароля Управление ключами 2 Долгосрочные и краткосрочные ключи Выбор длины ключа для защиты данных Выбор места хранения ключей 2 Оглавление Проблемы обмена ключами Создание собственных криптографических функций Использование одного ключа потокового шифрования Зачем нужно потоковое шифрование Подводные камни потокового шифрования "Что делать, когда необходимо использовать лишь один ключ Атаки на поточные шифры путем переворота бит Защита от атак переворота бит Что выбрать: хеш, хеш с ключом или цифровую подпись Повторное использование буфера для открытого и зашифрованного текста Криптография как средство защиты от атак Документируйте все случаи использования криптографии Резюме Глава 9 Защита секретных данных Атака на секретные данные Когда секрет хранить не обязательно Хеш с модификатором данных 2 Применение PKCS* 5 для усложнения задачи вааомщика Получение секретных данных от пользователя Защита секретов в Windows 2000 и следующих ОС семейства Частный случай: реквизиты пользователя в Windows XP Защита секретов в Windows NT 4 Защита секретов в Windows 95/98/Ме и Windows СЕ Получение информации об устройстве средствами РпР Слабость единого универсального решения Управление секретами в памяти Оптимизирующий компилятор... с подвохом Шифрование секретных данных в памяти Блокировка памяти для предотвращения выгрузки секретной информации на диск Защита секретных данных в управляемом коде Управление секретами в памяти в управляемом коде Поднимаем планку безопасности Хранение данных в файле на FAT-томе Применение встроенного ключа и операции XOR Применение встроенного ключа и алгоритма 3DES Использование 3DES для шифрования данных и хранение пароля в реестре Использование 3DES для шифрования данных и хранение пароля в защищенном разделе реестра Использование 3DES для шифрования данных, хранение пароля в надежном разделе реестра, а также защита самого файла и раздела реестра списками ACL Оглавление XI Шифрование данных по алгоритму 3DES, хранение пароля в надежном разделе реестра, требование ввести пароль, а также защита списками ACL файла и раздела реестра Компромиссы при защите секретных данных Резюме Глава 10 Все входные данные — от лукавого! Суть проблемы 2М Излишнее доверие 2:)б Методы защиты от атак, основанных на изменении входных данных Как проверять корректность данных 2 ) «Осторожные» переменные в Perl УЖ Регулярные выражения как средство проверки входящих данных Будьте внимательны с поиском (или проверкой) данных Регулярные выражения и Unicode Розеттский камень регулярных выражений Регулярные выражения в Perl Регулярные выражения в управляемом коде Регулярные выражения в сценариях Регулярные выражения в C++ Хороший подход, но без использования регулярных выражений 3Ю Резюме Глава 11 Недостатки канонического представления Что означает <• канонический» и как это понятие создает проблемы Проблемы канонического представления имен файлов Обход фильтров имен файлов в сервисе Napster Брешь в Mac OS X и Apache Брешь в именах устройств DOS Брешь в символической ссылке на каталог /tmp в пакете StarOffice компании Sun Стандартные ошибки в канонических именах Windows Проблемы приведения в канонический вид в Web Обход родительского контроля AOL Обход механизмов обеспечения безопасности еЕуе Зоны в Internet Explorer 4. Ошибка «IP-адрес без точек* Брешь, связанная с потоком ::$DATA в Internet Information Server 4.0 Две строки вместо одной 3 Еще одна напасть в Web — управляющие символы Атаки на основании визуального совпадения и томографические атаки ? Предотвращение ошибок приведения в канонический вид Никогда не принимайте решений на основании имен Используйте регулярные выражения как метод контроля имени 3 Отключайте генерацию имен файлов в формате «8.3» XII Оглавление Не полагайтесь на переменную PATH — указывайте полные имена файлов Самостоятельно приводим имена в канонический вид Безопасно вызывайте CreateFile ЗЗб Лекарства от болезни приведения в канонический вид в Web Контроль правильности входных данных Исключительная осторожность с UTF-8 LSAP1 — между молотом и наковальней На закуску: проблемы приведения в канонический вид, не связанные с файлами Имена серверов Имена пользователей Резюме Глава 12 Ввод в базу данных Суть проблемы Псевдосредство № 1: заключение вводимых данных в кавычки Псевдосредство №2: хранимые процедуры Средство № 1: никаких подключений к СУБД под учетной записью администратора Средство №2: построение безопасных SQL-выражений Создание безопасных хранимых процедур Глубокая оборона Резюме Глава 13 Проблемы ввода в Web-среде Кросс-сайтовые сценарии: когда выходные данные превращаются в монстров Иногда взломщик обходится без тэга

В процессе установки вам представится возможность определить другую папку.

Системные требования Большинство примеров создано на С или C++;

для них необходима Microsoft Visual Studio.NET, хотя многие прекрасно работают после компиляции другими компи ляторами, в том числе Microsoft Visual C++ 6.0. Примеры на Perl проверены в сре де ActiveState Perl 5.6 или ActivateState Visual Perl 1.0 (http://www.actwestate.com).

Введение XXIII Примеры на Microsoft VBScript и JScript протестированы на Windows Scripting Host, входящем в состав Windows 2000 и последующих ОС. Все примеры на SQL проье рены на Microsoft SQL Server 2000. Наконец, приложения на Visual Basic.NET и Visu al С# созданы и протестированы в среде Visual Studio.NET.

Все приложения в этой книге за исключением двух выполнялись на компью терах под управлением Windows 2000, конфигурация которых соответствует ре комендуемым требованиям этой ОС. Для нормальной работы примеров Safer из главы 7 и UTF8 из главы 11 требуется Windows XP или Windows.NET Server. Для компиляции кода требуются более мощные машины, удовлетворяющие требова ниям используемого компилятора к аппаратному обеспечению.

Техническая поддержка Мы постарались сделать все от нас зависящее, чтобы и сама книга, и дополнитель ные материалы не содержали ошибок. Издательство Microsoft Press постоянно обновляет список исправлений и дополнений к своим книгам и публикует их на сайте http://mspress.microsoft.com/suppon/. Если у вас все же возникнут вопросы или вы захотите поделиться своими предложениями или комментариями, обращу й тесь в издательство Microsoft Press на страничку http://ivww.microsoft.com/msprets/ support/searcb.asp.

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

Прежде всего мы благодарим сотрудников Microsoft Press, в том числе Дание ля Берда (Danielle Bird) — за согласие опубликовать это, второе издание нашей книги, Девона Масгрейва (Devon Musgrave) — за перевод нашего «потока созна ния» на литературный язык и предоставленные нам уроки грамматики, а также Брайана Джонсона (Brian Johnson) — за его заботу о том, чтобы мы в пылу пи< -а тельства не заврались. Также огромное спасибо Кэрри ДеВолт (Kem DeVault) за макетирование и Робу Нэнсу (Rob Nance) за прекрасные иллюстрации.

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

Саджи Абрахам (Saji Abraham), Юмит Аккуш (bmit Akkus.), Дуг Бейер (Doug В aye г), Тина Берд (Tina Bird), Майк Блашчак (Mike Blaszczak), Грант Болито (Grant Bolitho), Кристофер Брамм (Christopher Brumme), Нейлл Клифт (Neill Clift), Дэвид Кросс (David Cross). Скотт Калп (Scott Gulp), Майк Дансельо (Mike Danseglio), Бхавеш Доили (Bhavesh Doshi), Рамси Дау (Ramsey Dow), Вернер Дрейер (Werner Dreyer), Кедар Дубхаши (Kedar Dubhashi), Патрик Дассад (Patrick Dussud), Вадим Эйдельман (Vadjm Eydetman), Скотт Филд (Scott Field), Сайрус Грей (Cyrus Gray), Брайан Гранкемей ер (Brian Grunkemeyer), Каглар Гунякти (Caglar Gunyakti), Рон Джейкобе (Ron Jacobs), Йеспер Йоханссон (Jesper Johansson), Уиллис Джонсон (Willis Johnson), Лорен Конфелдер (Loren Kohnfelder), Сергей Кузин (Sergey Kuzin), Майк Лай (Mike Lai).

Брюс Лебан (Bruce Leban), Yung-Шин Лин (Yung-Shin Lin) по прозвищу «Bala». Стив Введение XXIV Липнер (Steve Lipner), Эрик Липперт (Eric Lippert), Мэтт Лайонс (Matt Lyons), Эрик Олсон (Erik Olson), Дейв Квик (Dave Quick), Apr Шелест (Art Shelest), Дэниел Сай (Daniel Sie), Франк Свидерски (Frank Swiderski), Мэтт Томлисон (Matt Thomlinson).

Крис Уокер (Chris Walker), Лэнди Ванг (Landy Wang), Джонатан Вилкинс (Jonathan Wilkins) и Марк Збиковски (Mark Zbikowski).

Мы также говорим «спасибо» всему отделению Windows за комментарии, пе дантичные замечания и уточнения — к сожалению, упомянуть каждого не пред ставляется возможным!

Некоторых хочется поблагодарить особо за то, что предоставили много мате риала для этой книги, причем основная его масса появилась в процессе кампа ний по безопасности соответствующих продуктов. Брэндон Брей (Brandon Bray) и Рэймонд Фокс (Raymond Fowkes) значительно помогли при сборе сведений о переполнении буферов. Дейв Росс (Dave Ross), Том Галлагер (Tom Gallagher)- и Ричи Лай (Richie Lai) — три ведущих эксперта по безопасности в Web, особенно по кросс сайтовым сценариям. Благодаря Джону МакКоннеллу (John McConnell), Мохаммеду Эль-Гаммалю (Mohammed El-Gammal) и Джули Беннетт (Julie Bennett) написана глава о проблемах при поддержке других языков, а работать с ними было огром ным удовольствием. Глава о безопасности кода в.NET осталась бы схематичной, если бы не помощь Эрика Олсона и Ивана Медведева;

особое спасибо Ивану за его идею «безопасности доступа к коду в картинках». Адриан Они (Adrian Oney) и Питер Вискарола (Peter Viscarola) из компании Open Systems Resources Inc. опе ративно создавали для нас примеры обращения с устройствами и режимом ядра.

Джей Си Кэннон (J.C. Cannon) взял на себя написание главы о конфиденциально сти. Наконец, Кэн Джонс (Ken Jones), Тодд Стэдл (Todd Stedl), Дейвид Райт (David Wright), Ричард Кэри (Richard Carey) и Эверетт МакКей (Everett McKay) предоста вили массу материала, который лег в основу главы о документации. Глава о вы полнении анализа безопасности кода значительно улучшилась благодаря исклю чительно полезным консультациям и рекомендациям Рамси Дау (Ramsey Dow) и презентации PowerPoint Нейла Клифта (Neill Clift). Вадиму Эйдельману принад лежит детальный анализ потенциальных проблем, возникающих при использо вании SO_EXCWSF/EADDR, и решений, которые вошли как в эту книгу, так и в ста тью базы знаний Microsoft Knowledge Base. Ваша готовность предоставлять такой богатый и обширный материал заслуживает самой высокой похвалы и благодар ностей.

А эти люди помогли нам при работе над первым изданием, и за это мы гово рим им огромное «спасибо*: Эли Аллен (Eli Allen), Джон Биккам (John Biccum), Томас Демл (Thomas Demi), Моника Эне-Пиетросану (Monica Ene-Pietrosanu), Шин Фин неган (Sean Finnegan), Тим Флихарт (Tim Fleehart), Дамиан Хаасе (Damian Haase), Дейвид Хаббард (David Hubbard), Луи Лафреньер (Louis Lafreniere), Брайан ЛаМакчья (Brian LaMacchia), Джон Ламберт Qohn Lambert), Лоренс Ландауер (Lawrence Lan dauer), Пол Лич (Paul Leach), Тэрри Липер (Terry Leeper), Руи Максимо (Rui Maximo).

Дэрил Песел (Daryl Pecelj), Джон Пискас (Jon Pincus), человек по прозвищу «Rain Forest Puppy*, Фриц Сэндс (Fritz Sands), Эрик Шульце (Eric Schultze), Алекс Сто ктон (Alex Stockton), Хэнк Войт (Hank Voight), Ричард Уард (Richard Ward), Ричард Веймир (Richard Wayrmre) и Марк Жу (Mark Zhou).

Введение XXV Много тех, кто не работает в Microsoft, пожертвовали своим временем, помо гая нам в работе над этой книгой. Мы благодарны Питеру Гатманну (Peter Gutmarm), Стиву Хейру (Steve Hayr) из компании Accenture, Кристоферу Клаусу (Christopher W. Klaus) из Internet Security Systems, Джону Пескаторе (John Pescatore) из Gartrier Inc., Герберту Эйч Томпсону (Herbert H. Thompson) и Джеймсу Эй Уайттекеру (James A. Whittaker) из Florida Tech и, наконец, Крису Уйсопалу (Chris Wysopal) по про звищу «Weld Pond* из компании @Stake.

И самое важное мы хотим поблагодарить всех и каждого в корпорации Microsi >ft за то воодушевление и рвение, с которым они отнеслись к инициативе «Довери тельные вычисления*. Огромное СПАСИБО вам всем!

ЧАСТЬ БЕЗОПАСНОСТЬ ПРИЛОЖЕНИЙ СЕГОДНЯ ГЛАВА Необходимость защиты систем Защищенное ПО —это программа, которая обеспечивает кон фиденциальность, целостность и доступность информации кли ента, а также целостность и доступность вычислительных ре сурсов, управляемых владельцем системы или системным адми нистратором.

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

Источник: Microsoft.com v_> развитием Интернета связи между приложениями, даже удаленными, стано вятся все теснее. В старые добрые времена компьютеры работали практически не зависимо друг от друга, причем связь между ними либо вообще отсутствовала, либо была очень слабой, а защита приложения считалась не столь важной: самое пло хое, что могло случиться, — разрушение системы на одной отдельно взятой ма шине. И пока приложение успешно справлялось со своими задачами, мало кого волновала его незащищенность. Подобный подход хорошо заметен во многих, ставших классическими книгах начала 90-х. Так, на 850-ти страницах блестящей монографии Стива Макконела (Steve McConnell) (Microsoft Press, 1993) практически не нашлось места проблемам безопасности. Не поймите нас превратно —- это дей ствительно замечательная книга, одна из тех, что в обязательном порядке долж Необходимость защиты систем ГЛАВА ны быть в личной библиотеке каждого разработчика. Просто за информацией о безопасности вам придется обратиться к иным изданиям.

Теперь же другие времена. В эру Интернета практически все компьютеры — серверы, ПК, карманные компьютеры и прочие специализированные устройства, такие как AutoPC и встраиваемые системы, а в последнее время даже сотовые те лефоны — объединены линиями связи. Это, конечно же, расширяет возможно сти разработчиков и открывает потрясающие перспективы для бизнеса, однако такие устройства легче атаковать. В частности, приложения, не предназначенные для работы в развитой сетевой (и поэтому потенциально недружественной) сре де, часто снижают общую защищенность компьютерных систем, делая их воспри имчивыми к атакам. А все потому, что разработчики просто не предполагали, что приложению придется работать в сети и оно может стать легкой добычей злоумь;

ш ленников. Задумывались ли вы когда-нибудь, почему World Wide Web часто назы вают Wild Wild Web* ? Прочитав эту главу, вы поймете причину. Интернет — враж дебная среда, и следовательно, любой код должен «уметь* противостоять атак ш.

Мы не паникеры В пятницу, 13 июля 2001 года, хакеры изуродовали страницы Web-сайта института системного администрирования, сетевых технологий н безопасно i;

era (System Administration, Networking and Security Institute, SANS) — bttp;

// ;

tewwsans,org. Ha следующей неделе SANS разослал по электронной почте всем подписчикам своего сетевого издания «SANS NewsBytes* письмо следующе го содержания: • Это было хорошее напоминание о том, насколько< разрушительной мо жет оказаться атака. Следует внимательнейшим образом проанали зировать абсолютно все программы и их параметры и в большинстве случаев модернизировать так, чтобы они противостояли не только атакам сегодняшним, но и тем, что возможны через года два. Некото рые наши сервисы останутся недоступными несколько ближайших дней, Действительно, Интернет — это враждебная среда. Подробнее о злона меренной модификации страниц сайтов (defacement) — на Web-странице Внимание! Никогда не следует рассчитывать, что ваше приложение будет ра ботать в определенных, заранее известных условиях. Наверняка найдутся «умники», использующие его в конфигурации, которую вы ну никак не могли предвидеть. Рассчитывайте на худшее: на работу в исключитель но недружественной, агрессивной среде, поэтому проектируйте, пиши те и тестируйте код с учетом именно таких условий.

Нелишне также помнить, что защищенная система — это качественная систе ма. Приложения, при создании которых с самого начала во главу угла ставилась Дикий, дикий Web, по аналогии с Wild Wild West (Дикий, дикий Запад). — Прим. пе^ев, Часть I Безопасность приложений сегодня защищенность, более надежны, чем те, защита которых достраивалась -вдогон ку». Защищенные продукты меньше критикуются средствами массовой информа ции, они более привлекательны для пользователей, а их сопровождение обходится дешевле. Высококачественный продукт немыслим без должного уровня безопас ности, поэтому придется при помощи пряника, а в особо тяжелых случаях и кну та, заставлять всех членов команды разработчиков помнить о безопасности кода.

Обо всех этих проблемах — далее в этой главе, кроме того, мы расскажем, как добиться, чтобы безопасность стала в вашей компании «приоритетом номер один».

Не трудитесь читать дальше, если качество кода вас не очень интересует.

Приложения в «дикой» Web-среде Мы часто размещаем компьютер в Интернете только для того, чтобы посмотреть, что с ним случится. Обычно не проходит и нескольких дней, как его обнаружи вают, исследуют и атакуют. Такие компьютеры обычно называют приманкой (honey pot*), их используют для наблюдения за действиями хакеров.

Примечание Чтобы больше узнать о приманках и о том, как хакеры проника ют в компьютерные системы, рекомендуем познакомиться с проектом Honeynet (project.honeynet.org).

Мы наблюдали процесс обнаружения и атаки компьютера, когда в середине 90-х работали над Web-сайтом http://www.ivindows2000test.com, на котором защиту Windows 2000 тестировали в условиях «реального боя». Сейчас этот сайт не фун кционирует. В пятницу мы тихо разместили Web-сайт в Интернете, а к понедель нику его уже массированно атаковали. И это несмотря на то, что мы о нем нико му ничего не говорили.

Смысл сказанного ясен, как белый день, — атаки неизбежны. Хуже того, сейчас перевес явно на стороне хакеров, и в разделе «Правила боя* мы объясним почему, Некоторые взломщики действительно относятся к разряду высококвалифици рованых и талантливых. Они вооружены глубокими знаниями о компьютерах, и у них масса энергии и времени на исследование приложений на предмет уязви мости. Не скрою, я с уважением отношусь к некоторым из этих ребят, особенно к так называемым «белым шляпам» (white-hats), или «хорошим» хакерам, которые исследуют защиту систем в «мирных целях»;

со многими из них я знаком лично.

Лучшие представители племени «белых хакеров» тесно сотрудничают с произво дителями ПО, в том числе с Microsoft. Обнаружив серьезную брешь в системе безопасности, они сообщают об этом производителю. Тот принимает соответству ющие меры: выпускает «заплату» или предлагает пользователям изменить конфи гурацию приложения. Такой подход помогает Интернет-сообществу не оказаться безоружным перед вандалами, которые, обнаружив уязвимое место, проводят широкомасштабную атаку.

Большинство взломщиков — просто глупые вандалы, их еще называют люби телями (script kiddies), Они мало разбираются в защите и способны атаковать незащищенные системы, лишь пользуясь сценариями (scripts), созданными более Дословно «горшочек с медом*. — Прим. перев.

ГЛАВА 1 Необходимость защиты систем грамотными взломщиками — теми, кто находит бреши, документирует их и пи шет код, их «эксплуатирующий» (в английском такой код называется exploit code, или просто exploit, есть и более короткий вариант — sploit).

О том, как обнаружили тестовый Web-сайт Windows Вы, верно, думаете, что никто не найдет компьютер, «втихую» размещен ный в Интернете? А зря. Тестовый сайт Windows 2000 обнаружили практи !

чески сразу, и вот как это произошло. (Не переживайте, если вам незнако мы некоторые понятия в этом рассказе — мы их объясним далее по ходу изложения.) Кто-то (взломщик), сканируя внешние IP-адреса, принадлежа щие Microsoft, обнаружил новый действующий IP-адрес — он принадлежал нашему серверу. Затем взломщик проверил порты сервера, выясняя, какие из них открыты. Эта процедура называется сканированием портов (port scanning). Открытым оказался только 80-й — порт протокола передачи ги пертекста (Hypertext transfer protocol, HTTP). Поэтому наш «друг* направил на сервер HTTP-запрос с командой HEAD, пытаясь выяснить, какое сервер ное ПО установлено на Web-сервере. Это был Internet Information Services (HS 5), который на тот момент еще официально не посташшлся. Затем взлом щик запустил Web-браузер, ввел IP-адрес сервера и узнал, что это тестовый ;

• Web-сайт, поддерживаемый командой тестирования Windows 2000, и его до менное имя — www.windows2000test.com. Тогда он отправил сообщение о своей находке на сайт bttp://wwufslash4ot,org, и уже через несколько часов,•• ;

сайт оказался под массированной атакой.

Подумать только, а ведь see, что мы сделали, — разместили сайт в Ин тернете! И только., Вот от них-то и следует ждать неприятностей. Представьте, что вы выпустили приложение, хакер обнаружил брешь в защите и опубликовал exploit до того, к;

;

к вы ее устранили. Теперь не отягощенный чувством ответственности любитель может приятно провести время, атакуя все подключенные к Интернету компьи > теры, на которых работает ваше приложение. Я сам много раз оказывался в T.I ком дурацком положении. Ощущения при этом испытываешь ужасные: пря\.о скажем — приятного мало. Пытаясь решить проблему, люди начинают метаться и суетиться. Хаос наяву! Лучше заблаговременно принять все возможные меры, чтоб ы исключить подобную ситуацию, и здесь единственный способ — проектирова- ъ защищенные приложения, способные противостоять атакам.

Конечно, этот аргумент эгоцентричен — я рассмотрел проблему с точки зре ния разработчика. В долгосрочной перспективе «дырявая» система обойдется вам дорого и испортит вашу репутацию, что, в свою очередь, повлечет падение npi > даж, отток клиентов, переключение их внимания на продукты конкурентов, ко торые, как им кажется, лучше защищены. А теперь предлагаю взглянуть на про блему с точки зрения, которая действительно важна, — с «колокольни* конечн' > го пользователя!

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

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

Безусловно, многое предстоит сделать, чтобы компьютеры по-настоящему за воевали наше доверие. Предстоит решить множество сложных проблем, напри мер, как сделать системы самовосстанавливающимися (self-healing). Зашита боль ших компьютерных сетей — также очень интересная и нетривиальная задача. Эта книга как раз и посвящена созданию систем, на которые можно положиться пол ностью, «Танцуют все!» Фраза «безопасность превыше всего* должна стать корпоративным девизом, ведь, как известно, необходимость поставлять защищенное ПО сейчас важна, как ни когда ранее. Пользователи требуют защищенных приложений и считают это сво им правом, а не привилегией. К тому же менеджеры отдела продаж конкурирую щих фирм не поленятся лишний раз напомнить вашим потенциальным клиентам, что ваш код небезопасен и ненадежен. Итак, ясно, что необходимо создавать в компании идеологию безопасности. Но с чего же начать? Лучше всего сверху, но это потребует немалых усилий. Вам придется доказать начальству, что укрепле ние защиты улучшит показатели прибыльности компании. Безопасность часто воспринимается как досадная помеха, к тому же очень затратная и совсем (или практически) не дающая положительного финансового результата. Кроме того, от Необходимость защиты систем ГЛАВА вас потребуется масса такта, хотя иногда и откровенно партизанские действия нелишни. Итак, что же имеется в виду под методами «убеждения*?

Тактичные методы пропаганды идей безопасности Для демонстрации того, что защищенные приложения — благо для вашего биз неса, требуются аргументы — и весомые. Лучшими можно считать те. что непо средственно касаются прибыли компании. Вам следует достаточно прозрачно объяснить руководству, что пренебрежение ими, скорее всего, негативно отразится на бизнесе.

Защищенный — значит качественный Эту идею легко «продать» вашему руководству. Достаточно спросить, заинтересо вано ли оно в создании качественного продукта. Здесь единственный правильный ответ — да! В противном случае мы бы порекомендовали вам поискать работ* в другом месте — там, где ценят качество.

Ну ладно, ладно, мы немного упростили, ведь мы не говорим об идеальном программном обеспечении. (Как шутят специалисты по безопасности, идеально защищена та компьютерная система, что выключена и захоронена в бетонном бун кере;

но и ее безопасность обеспечена не «на все сто».) Мы говорим о ПО, кото рое достаточно защищено и качество которого соответствует условиям его рабо ты. Так, на защиту сетевой игры потребуется существенно меньше времени и усилий.

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

Необходимость и уровень защиты определяются конкретной ситуацией — точ) ю так же, как для разных целей требуются разные решения. — однако заведомо из вестно одно: защита является подмножеством качества. Не защищенный должным образом продукт проигрывает. Некоторые подумали, что безопасность также яв ляется подмножеством надежности, но все зависит от того, что понимать под безопасностью. Так, решение, защищающее секретные данные, не обязательно должно быть надежным. Систему, которая регулярно «падает*, но не нарушает секретность данных, по-прежнему можно считать безопасной. Как показано на рис. 1-1. забота о качестве или надежности означает борьбу за безопасность.

Зачем нужна безопасность в сетевой игре Это может показаться странным, но сетевые игры тоже подвергаются ата кам. Представьте, что вы выпустили сетевую многопользовательскую стра тегическую игру типа Microsoft Age of Empires 2, но вокруг обнаружилось, •! что недобросовестный игрок может «убить* другого, отправив ему вредо носный пакет данных. Чувствуя, что проигрывает, нечестный игрок просто отправляет «пакет смерти» оппоненту. Такое поведение вряд ли можно на звать спортивным, но оно возможно, и ваша задача — оградить пользова телей от подобного жульничества.

2- Часть I Безопасность приложений сегодня Качественное ПО Рис. 1-1. Защищенные программы — подмножество качественного и надежного ПО Пресса (и конкуренты) "перемывают косточки» вашей программе Нравится вам это или нет, но СМИ хлебом не корми, только дай пошуметь о про блемах с безопасностью. Журналисты не всегда понимают, о чем пишут, и часто в погоне за сенсацией делают из мухи слона. Почему бы не проигнорировать одни факты и не сгустить краски, описывая другие? Люди склонны верить прочитан ному или услышанному, поэтому, если о недостатке — серьезном или не очень — в защите вашей программы говорилось на первой полосе, будьте уверены — со трудникам вашего отдела продаж и маркетинга после придется долго расхлебы вать кашу, заваренную рьяными борзописцами. Поговорка о том, что «любой скан дал — прекрасная реклама», в случае проблем с безопасностью просто не работа ет. Такая «реклама» подтолкнет ваших клиентов в объятия конкурентов с их вро де бы более надежными продуктами.

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

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

ГЛАВА 1 Необходимость защиты систем Устранение недостатков — дорогое удовольствие Как и любые изменения конструкции ПО, устранение недостатков защиты на поздних этапах разработки обходится значительно дороже. Сложно определить точную сумму из-за большого числа нематериальных составляющих, к которым ОТНОСЯТСЯ:

• затрамы на координирование процедуры исправления;

• оплата работы разработчиков, отыскивающих уязвимые места кода;

• оплата работы программистов, исправляющих код;

• оплата тсстировщиков, проверяющих код после внесения корректировок:

• затраты на тестирование программы установки пакета исправлений;

• затраты на создание и тестирование версий для разных языков;

• затраты на цифровое подписание пакета исправлений, если поддерживаете я технология подписи кода, например Authenticodc;

• стоимость публикации пакета исправлений на Web-сайте;

• оплата технических писателей, создающих документацию для пакета испраи лений;

• расходы на PR-кампанию, направленную на устранение плохого впечатления от наличия дыр в защите ПО;

• аренда линии связи у Интернет-провайдера (ISP);

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

• затраты клиентов на установку пакета исправлений. Им придется сначала ус тановить исправления на тестовом сервере и проверить, как исправленное приложение станет работать в их ИТ-среде. Опять-таки — люди, занятые те стированием и установкой пакета исправлений, могли, по идее, потратить это время на более полезную работу;

• и, наконец, потерянная прибыль из-за того, что потенциальные клиенты ре шили отложить или вообще отказались от использования вашего продукта.

Как видите, стоимость внесения одного исправления в систему безопасное] и тянет на десятки, если не на сотни тысяч долларов. А что стоило поставить защ) ( [ценность во главу угла при проектировании и разработке продукта!

Примечание Несмотря на сложность определения точной суммы затрат при выпуске пакета исправлений системы безопасности, Центр по безопас ности Microsoft (Microsoft Security Response Center) полагает, что брешь в защите, требующая выпуска бюллетеня, обходится приблизительно в 100 000 долларов.

Рекомендуем еще один источник, откуда можно почерпнуть массу веских о : нований для назначения безопасности высокого приоритета — раздел интеллек туальной собственности и компьютерных преступлений (Computer Crime and Intellectual Property Section, CCIPS) на Web-сайте Министерства юстиции США (ЬЩ):// www.cvbercrime.gov). Здесь собрано огромное количество рассказов об уголовных Безопасность приложений сегодня 10 Часть I делах, связанных с компьютерными преступлениями, а также описание ущерба, выраженное в конкретных суммах. Покажите эти данные генеральному директо ру — возможно, он не представляет, во что обходится нарушение системы безо пасности.

А теперь несколько слов о необычных методах привлечения внимания руко водства к необходимости серьезного отношения к безопасности.

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

• удаленная остановка приложения — серьезный недостаток;

• атаку удавалось выполнить анонимно;

• возможно написать сценарий (script) для автоматизации атаки, которым с ра достью воспользуются любители;

• на исправление ошибки команде достаточно одного дня работы (так почему бы это не сделать сейчас, пока не поздно?);

• если ошибку исправить сейчас, то в долгосрочной перспективе вырисовыва ется значительная экономия средств;

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

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

Но веские аргументы остались без внимания. Нас это очень волновало, так как ошибка была действительно серьезной. К тому времени мы уже написали простой сценарий па языке Perl, удаленно останавливающий приложение. И нам пришлось выступить в роли «нехорошего дяди»: мы остановили приложение, работающее на сервере команды, где выполнялось тестирование. Каждый раз, когда они пере запускали приложение, мы его останавливали. Это было несложно. При запуске программа открывала определенный порт протокола TCP (Transmission Control Protocol), поэтому мы модернизировали свой Perl-сценарий: теперь он отслежи вал порт, и как только тот подавал признаки жизни, сценарий «убивал» приложе ние специальным пакетом данных. Разработчики исправили ошибку, поскольку на своей шкуре почувствовали, какая незавидная судьба ожидает пользователей, ГЛАВА 1 Необходимость защиты систем При ближайшем рассмотрении ошибка — заурядное переполнение буфера — и исправление оказались тривиальными.

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

Примечание Что в данном случае означает слово завладеть (own)? На хакер ском сленге это означает получить полный несанкционированный до ступ к компьютеру. Часто говорят, что система является Own3d (owned — принадлежит). Да-да, написано правильно! Хакеры любят смешивать числа и буквы при написании слов. Например, цифра «3» обозначает букву «е» (видимо, из-за сходства с перевернутой большой английской буквой «Е»), цифра «О» обозначает букву «О» и так далее. Может, вы также слы шали, как говорили о рутированной (rooted) системе или как кто-то стал рутам (root). Эти термины происходят от названия учетной записи су перпальзователя (superuser), которая в Unix называется гоос. Учетные записи Administrator (Администратор) или SYSTEM в ОС Microsoft Win dows NT/2000/XP имеют такой же уровень доступа.

Конечно, это радикальная мера. Мы никогда не выкидывали подобных фоку сов;

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

Внимание! «Диверсии» стоит применять, когда вы абсолютно уверены в серь езности дыры в защите. Не сейте панику и не лезьте на рожон.

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

Некоторые методы насаждения идей безопасности Теперь, когда вы привлекли внимание генерального директора, самое время по заботиться о воспитании культуры безопасности в производственных подраз,;

е лениях — там, где делают приложение. Как оказывается, дизайнеров, разработчи ков и тестировщиков обычно довольно легко убедить в важности безопасности, поскольку большинство из них заботится о качестве продукта. Очень неприятно читать обзор, где говорится о недостатках защиты только что выпущенного при ложения, не говоря уже о передаваемом из уст в уста мнении пользователей, ьо Безопасность приложений сегодня 12 Часть I торые обнаружили серьезные дыры в системе безопасности любовно созданно го вами продукта. В следующих разделах описывается несколько приемов, позво ляющих сформировать особую атмосферу заботы о безопасности и защите со здаваемого приложения.

Убедите начальника обратиться к сотрудникам с заявлением на тему безопасности Если вам удалось привлечь внимание босса к животрепещущей проблеме, теперь следует убедить его довести мнение по данному вопросу до сведения всех сотруд ников. Простейший способ — разослать сообщение электронной почты или слу жебную записку, в которой объясняется, почему безопасность ставится во главу угла. Один из лучших образцов, который мне удалось увидеть лично, — послание Джима Олчина (Jim Allchin), вице-президента группы Windows в Microsoft. Вот отрывок из письма, адресованного разработчикам Windows:

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

Ответственность за защищенность Windows XP лежит на каж дом. Я говорю не о дополнительных возможностях подсистемы защиты, а о качестве реализации каждой возможности.

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

У нас лучшая вмире команда разработчиков, имы прекрасно зна ем, что должны создавать код без проблем с безопасностью — и точка. Я не хочу, чтобы после официального выпуска в Windows XP обнаружившись бреши в защите, подвергающие риску наших клиентов, Джим Джим Олчин выразился предельно ясно и недвусмысленно. Суть его послания проста: безопасности присваивается наивысший приоритет. Когда такие письма приходят «сверху», чудеса становятся возможными наяву. Конечно, это не озна чает, что в продукте не останется ни одной ошибки. Если уж говорить откровен но, то после выхода Windows XP несколько ошибок подсистемы безопасности все Необходимость защиты систем ГЛАВА таки было найдено, и вряд ли они последние. Но общее направление ясно: под нимать планку от версии к версии с тем, чтобы дыр обнаруживалось все меныле и меньше.

Самый громкий призыв к действию прозвучал из Microsoft в январе 2002 года, когда Билл Гейтс разослал всем сотрудникам компании памятную записку * Дове рительные вычисления» (Trustworthy Computing), в которой подчеркивал важное 'ь выпуска более защищенных и надежных приложений по причине возрастания угрозы компьютерным системам. Интернет три года назад разительно отличае г ся от нынешней Сети — она куда враждебнее, и приложения необходимо проек тировать с учетом этого. Текст меморандума Билла Гейтса вы найдете на Web-стра нице neu-s.com.com/2009-1001 -81 J21Q.html.

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

• быть в курсе всех новинок в сфере безопасности;

• проводить собеседования с кандидатами в команду поддержки процедур бе зопасности в компании;

• учить сотрудников, как обеспечивать безопасность;

• назначать вознаграждения за самый безопасный код или за самое падежное исправление ошибки защиты. В качестве вознаграждения годится все: денеж ные премии, отгулы, выделение персонального почетного места парковки на месяц — да мало ли что еще;

• распределять обнаруженные ошибки по приоритетам в соответствии с их опасностью и давать советы, как лучше устранять обнаруженные бреши, А теперь более детально о том. как выполнять эти обязанности.

Держите руку «на пульсе» На сегодня имеются два лучших ресурса с постоянно обновляющейся информа цией: сайты NTBugTraq и BugTraq. Первый целиком посвящен Windows NT, а на втором рассматриваются более общие вопросы. Поддержку NTBugTraq осуществ ляет Расе Купер (Russ Cooper), а подписка на рассылку доступна на сайте ЬПр:// www.ntbugtraq.com. BugTraq, объединяющий самые известные списки рассылки, посвященные брешам в защите и их обнаружению, поддерживается компанией SecurityFocus, принадлежащей в настоящее время Symantec Corporation. Подписав шись на рассылку на сайте http://wwwsecurityfocus.com, вы ежедневно станете по лучать около 20 писем. Знакомство с информацией о новостях в сфере безопас ности из публикаций NTBugTraq и BugTraq должно стать частью ежедневной p.i боты «'Старшого» по безопасности, Рекомендуем обратить внимание и на другие предложения Security-Focus (blip:// www.securityfocus.com), такие как Vuln-Dev, Pen-Test и Sec-Prog.

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

Интервьюируя в Microsoft кандидатов на позиции, связанные с безопасностью, мы обращаем внимание на качества претендентов, в том числе на:

• страсть к предмету. Про таких людей говорят, что «у них горят глаза*;

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

• горячее желание создавать защищенное ПО, удовлетворяющее реальным тре бованиям пользователей и бизнеса:

• способность находить нестандартные (но приемлемые в конкретной ситуации) способы применения теоретических знаний о безопасности;

• способность предлагать конкретные решения, а не просто ставить вопросы, Жаловаться на проблемы — штука нехитрая;

• способность понимать ход мыслей взломщика;

• способность изменить заданную роль. Часто требуется способность действо вать, как атакующий. Да-да, чтобы дать отпор хакерам, вы должны уметь делать то же, что и они.

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

Этим, как правило, грегыат компьютерные фанаты и продвинутые пользо ватели. Они знают самые заковыристые возможности системы и значение.загадочных сообщений об ошибках, и им кажется, что обычные пользова тели владеют таким же знанием. Им трудно залезть в шкуру пользователя, поэтому они просто не понимают их проблем. А если ваше ПО приобрета ют организации, вы должны понимать не только пользователей, но и ИТ~ менеджеров: знать, как. они управляют компьютерами и серверами. Грань между просто защищенными, защищенными и пригодными к работе пользо • вателей системами чрезвычайно тонка. Только профессионалы в области безопасности способны ее различить..

Основная черта специалиста по защите — одержимость. Профессионала хле бом не корми — дай «помудрить* в защите ИТ-систем и сетей. Профессионалы Ъ ГЛАВА 1 Необходимость защиты систем безопасности этим живут, а значит, способны защитить систему лучше всех. (Знае ч, что повторяемся, но все-таки: человек должен делать то, что ему нравится, в пр> *> тивном случае следует просто сменить дело.) Другая важная составляющая — это опыт, особенно «шишки», набитые при латании брешей защиты в условиях «реального боя». Такой опыт дорогого стоит, и им необходимо делиться с коллегами, В 2000 году началось затяжное снижение американского фондового рынка, что очень многим игрокам стоило кучу денег. Как нам кажется, это произошло из- ia того, что их финансовые консультанты не имели опыта «медвежьего» рынка. В их памяти только хорошие времена, когда рынок уверенно рос, и они давали своим клиентам единственный совет — вкладывать деньги в сильно переоцененные дст комы. К счастью, финансовый консультант Майка (одного из авторов этой кн-л ги) много повидал на своем веку и поэтому принял за него ряд мудрых решений, Благодаря ему Майк пострадал не так сильно, как большинство. Если вы найде ге человека с подобным опытом, держитесь за него обеими руками.

Организуйте процесс непрерывного обучения Ожидая первого ребенка, один из авторов с женой посещали курсы по оказана ю первой помощи новорожденным. Когда в конце занятия инструктор, врач скор) >й помощи, поинтересовался, нет ли у нас вопросов, наш автор поднял руку и ска зал, что уже завтра присутствующие забудут большую часть сказанного, поэтому спрашивается: что инструктор посоветует, чтобы не утратить полученные навы ки. Ответ был прост: еженедельно перечитывать конспект курса и практиковать ся. То же самое справедливо и отношении безопасности: вы должны добиться, чтобы ваши не очень сведущие в безопасности коллеги получили возможность регуляр но освежать свои знания. Например, команда «Безопасная Windows» (Secure W i n dows Initiative) в Microsoft выбрала следующую тактику:

• создала сайт в интрасети, посвященный безопасности. На него сотрудники обращаются при возникновении любых проблем с безопасностью:

• опубликовала «белую книгу» (white paper), в которой описаны провереннее практикой методы обеспечения безопасности. По мере обнаружения и устра нения брешей в создаваемом ПО процесс латания дыр тщательно документи ровался и эта информация публиковалась для открытого доступа всем сотруд никам;

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

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

Часть I Безопасность приложений сегодня Мы считаем такой подход очень полезным, поскольку он каждую неделю на поминает людям о необходимости соблюдать безопасность;

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

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

Классифицируйте ошибки системы безопасности Иногда приходится принимать решение: устранять или нет ту или иную брешь.

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

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

Любое ПО, которое устанавливается на компьютер, особенно подключенный к Интернету, необходимо защищать. Имеется в виду то, что код приложения ста новится постоянно — 24 часа в сутки, 7 дней в неделю — доступным для атаки из любой точки земного тара. Поэтому он должен противостоять атакам, чтобы не стать причиной компрометации, повреждения, удаления или перлюстрации зло умышленником защищаемых системой ресурсов. В подобной, исключительно слож ной ситуации оказываются пользователи всех компьютерных систем. Это также создает проблемы производителям ПО, так как их продукты становятся потенци альной мишенью для атак.

А теперь об особенностях обороны и защиты.

ГЛАВА 1 Необходимость защиты систем Правило №1: защищающемуся приходится охранять все слабые места, а нападающему достаточно выбрать одно из них Допустим, вы держите оборону в неплохо оборудованном замке: каменные стены толщиной в 5 футов* с бойницами, глубокий ров с водой, подъемный мост. Часо вые постоянно патрулируют стены замка, мост большую часть времени поднят, а когда его опускают, специальный отряд зорко следит за воротами. Вам пришлось позаботиться о хорошей экипировке стрелков, о средствах тушения огня — на слу чай, если вас обстреляют горящими стрелами, а также о провизии на случай осады, Нападающему же достаточно отыскать всего одно слабое, плохо защищенное место, То же самое справедливо в отношении ПО: нападающему хватит единственной бреши в защите вашего приложения, а вы обязаны «закрыть» все слабые места, Конечно, если какая-то возможность отсутствует — то есть не была установлена или отсутствует в программе, — то и воспользоваться ею для атаки не удастся Правило №2: защищающийся готовится отразить известные атаки, а нападающий может разработать новые методы взлома Допустим, в вашем замке есть колодец, питаемый подземной рекой. Задумывались ли вы, что нападающий может проникнуть в замок именно через него, пройдя по руслу подземной реки? Помните историю падения Трои? Троянцы не разглядели опасности в подарке греков и поплатились за это жизнью.

Система безопасности ПО разрабатывается только для теоретически вычислен ных или предугаданных атак. Так, разработчики IIS 5 знали, как защитить сервер от атак с использованием управляющих символов (escape character) в URL-адресе, но оказались не готовы к атакам с применением нестандартных последователь ностей символов в формате UTF-8 — они просто не знали о существовании этой возможности. А хакер, изрядно потрудившись, отыскал-таки ошибку в обработке некорректных последовательностей символов. Подробный «отчет о проделанной работе* опубликован на Web-странице bttp://www.wiretrip.net/rfp/p/doc.asp/i2/ d57.btm.

Единственный способ защититься от атак заранее неизвестного типа — отклю чить все возможности программы, которые явно не востребованы пользователем.

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

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

Безопасность приложений сегодня 18 Часть I траторов. которым приходится постоянно контролировать работу системы, про верять журналы, обнаруживать и отражать атаки. Таким образом, разработчики должны предусмотреть в ПО средства противостояния атакам и инструменты для мониторинга системы, помогающие пользователям выявить атаку.

Правило №4: защищающему приходится соблюдать правила, а нападающему не возбраняется вести «грязную игру» Хоть в мире ПО это и не всегда так, но по большей части это утверждение верно, В распоряжении защищающегося масса хорошо изученных средств, разработан ных «белыми хакерами* (например, брандмауэры, системы обнаружения вторже ний, журналы аудита и «приманки») для защиты системы и обнаружения атак. На падающему же ничто не мешает прибегнуть к любому доступному ему средству проникновения в систему и обнаружения слабых мест в защите. И в этом случае преимущество на его стороне, Резюме Итак, понятно, что положение защищающегося не из приятных. Разработчикам ПО приходится создавать «постоянно бдящие* приложения, однако преимущество на стороне нападающих, и слабо защищенную программу они быстро взломают.

Короче говоря, чтобы нейтрализовать хакеров, нужно действовать весьма и весь ма умно. Говоря это, я все равно сомневаюсь, удастся ли нам когда-нибудь наго лову разгромить Интернет-вандалов — их слишком много, так же как и доступ ных для атак серверов. Кроме того, многие «шалуны* атакуют компьютеры в Ин тернете просто потому, что им это удается! Вспоминается интервью с Джорджем Меллори (George Mallory) (1886—1924), который на вопрос: «Почему вы хотите покорить Эверест?» ответил: «Просто потому, что он есть на свете». Но все же мы в состоянии поднять планку защиты до такого уровня, что хакерам придется при знать, что атаковать наши программы слишком хлопотно, и поискать лучшее при менение своим силам.

И, наконец, знайте, что безопасность занимает особое положение в мире ком пьютеров. За исключением разработчиков очень немногие люди (если таковые вообще имеются) активно интересуются вопросами масштабируемости и локали зации ПО. Однако многие склонны тратить время и деньги, чтобы в поте лица искать дыры в защите. Интернет — крайне сложная и агрессивная среда, и ваши приложения должны уметь выживать в ней.

ГЛАВА Активный подход к безопасности при разработке приложений Е)олыиинство изданий, посвященных созданию безопасных программ, ограни чиваются только одной составляющей — кодом. Мы решили нарушить эту тради цию и рассказать обо всем, что нам кажется важным: о проектировании, програм мировании, тестировании и документировании ПО. Каждый из этих процессов исключительно важен для создания безопасных систем, и. совершенствуя их, очечь важно соблюдать жесткую дисциплину. Одного лишь добавления пары-тройки «хороших идей», горстки «лучших практик* или поэтапных инструкций в не очень хорошо организованный процесс разработки недостаточно для существенного повышения безопасности конечного продукта. Мы познакомим вас с некоторы ми общими методами переориентации процессов разработки ПО на укрепленле безопасности и уделим достаточно внимания проблемам образования и обучен! но безопасности, так как это критически важно для создания защищенных продук тов, кроме того, это наш любимый конек, а также детально обсудим методы про паганды безопасности и внедрения жесткого контроля защиты на каждом этапе разработки.

А сейчас давайте выясним, почему большинство далеко не обделенных инт< л лсктом людей делает ошибки и оставляет ПО незащищенным. Вот основные пр>и чины, по которым игнорируются требования по безопасности:

• безопасность навевает смертную скуку;

• защита часто ограничивает функциональность продукта, она «путается под ногами» и мешает полноценной работе;

• безопасность сложно измерить:

Безопасность приложений сегодня 20 Часть I • безопасность обычно не представляет собой главную специальность или пред мет заинтересованности проектировщиков и разработчиков;

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

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

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

Вторая причина — весьма распространенное отношение, отчасти основанное на заблуждении. Согласно требованиям безопасности рекомендуется запретить пользователю доступ к функциям, которые ему не нужны. Представьте себе, что получится, если из соображений удобства использования (usability) приложение создано так, что персональную информацию и номера кредитных карточек кли ентов можно узнать без предварительных процедур аутентификации и авториза ции. Ясно, что этими сведениями смогут воспользоваться все, в том числе не отя гощенные моральными принципами субъекты! А теперь поставьте себя па место клиента;

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

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

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

И последнее: чем больше функций в программе, тем выше вероятность обна ружения дыр, ведь взломщик «анализирует* каждую функцию. Новые возможнос ти по сути своей опаснее, чем проверенные и активно используемые, но большин ство разработчиков, как люди творческие, предпочитают решать новые задачи, со здавать новые функции или выдумывать новые способы реализации старых. Билл Гейтс подчеркнул это в своем меморандуме «Доверительные вычисления»: «Ока Активный подход к безопасности при разработке приложений ГЛАВА 2 :

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

А теперь посмотрим, как решать перечисленные проблемы, Совершенствование процессов На время забудем об обучении всех членов команды разработчиков (об этом ч\ть позже) и поговорим о совершенствовании процессов разработки. Мы предлага ем очень простую вещь — вносить улучшения в процесс на каждом этапе проекта независимо от используемой модели этапов разработки ПО.

На рис. 2-1 показаны некоторые новшества, позволяющие повысить ответствен ность сотрудников и улучшить структуру процессов разработки ПО с точки зре ния безопасности. В спиральной модели достаточно предусмотреть циклические процедуры, а если вы используете водопадную модель (waterfall approach), про сто позаботьтесь о дополнительных этапах ниже «по течению», выполняемых в фоновом режиме. А сейчас детально об особенностях подобных операций.

О О О О Обсуждение Моделирование Определение Сторонняя Кампания Обратная вопросов опасностей предельного экспертиза по обеспечению связь безопасности числа ошибок / безопасности в процессе / в процессе / ора требований / и в конце проекта/ Поставка и сопровождение s / / 1/< у клиента Тестирование Разработка Проектирование • 1 ' :

\и Концепция Готовый Готовые планы Готовь Поставка проект тестирования код Легенда \ I 1 f ~ j непрерывно -Ан<1лиз старых ошибок Анализ Тесты командой. на отсутствие • Пе епроверка кода • Рус оводство по написании ) безопасного кода Обучение отвечающей мутации данных О за безопасность и исполнение О при минимальных привилегиях Рис. 2-1. Укрепление защиты в процессе разработки ПО на каждом этапе Вы увидите, что многие этапы выполняются итеративно и непрерывно. Так.

сотрудников в группу набирают не только в начале проекта — это непрерывная составляющая часть процесса.

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

Часть I Безопасность приложений сегодня Необходимость обучения Я уже говорил, что обучение безопасности — мой конек;

точнее, недостаточность такого обучения — мой любимый «мальчик для битья*. А особо потешить эту свою слабость мне пришлось в первой четверти 2002 г., когда в Microsoft объявили кам панию по укреплению безопасности Windows (Windows Security Push). В рамках этого мероприятия мы за десять дней обучили примерно 8500 человек. Да. да, я не оговорился! Мы потребовали, чтобы все члены всех команд, участвующих в создании кода, попавшего на установочный диск Windows (а число команд за шкаливает за 70), посетили семинары, в том числе и вице-президенты! Мы разра ботали три курса, и каждый пришлось прочитать 5-6 раз. Первый курс адресовал ся разработчикам, второй — тестировщикам, а последний — менеджерам проек тов. (В Microsoft менеджеры проектов отвечают полностью за весь набор функ ций приложения.) Специалистам по документации предлагались курсы в соответ ствии с областью, в которой они работают. Вы не поверите, но нашлись мазохи сты, прослушавшие все три курса!

К чему мы клоним? Мы считаем эту акцию необходимой. Успех кампании по безопасности невозможен без повышения понимания и сознательности каждого сотрудника. Дэвид, второй из авторов этой книги, любит повторять: «Люди хотят делать вес «правильно», но подчас не знают, как это — «правильно». В этом случае им нужно помочь». Многие программисты понимают, как внедрять в ПО функции безопасности, но большинству из них никто не объяснял, как создавать безопасные системы. Я убежден, что в институте многому учат неправильно или, по крайней мере, не всегда преподают «правильные» вещи. Не поймите меня превратно: в ИТ-отрасли обучение играет огромную роль, но все начинается в учебном заведении.

Лучше всего объяснять, что мы имеем в виду, на примере. В феврале 2002 г. я временно прервал участие в Windows Security Push для участия в круглом столе на «Симпозиуме по безопасности сетей и распределенных систем» (Network and Distributed System Security Symposium, NDSS) в Сап-Диего, на котором обсуждались вопросы Интернет-приложений. В своем выступлении я упомянул о собеседова нии, которое провел за несколько месяцев до этого. Мне требовалось отобрать человека в команду Secure Windows I n i t i a t i v e, который бы оказывал другим груп пам разработчиков помощь в проектировании и программировании безопасных приложений. На интервью я спросил кандидата, как укрепить защите средствами RSA (Rivest-Shamir-Adlcman), алгоритма шифрования с открытым ключом. Претен дент начал подробно рассказывать, о том что «нужно взять два очень больших простых числа Р и Q...», — в общем, он стал пересказывать, как работает алгоритм RSA. но не как его применять. Я повторил вопрос: меня интересует, не как рабо тает RSA (это черный ящик, созданный и изученный профессионалами и, надо полагать, работающий именно так, как обещают его создатели), а как применить эту технологию для защиты. Кандидат признался, что не знает, и этого было до статочно;

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

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

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

Внимание! Пусть вашим девизом станет: <-Функции безопасности = Безопасные функции».

По завершении круглого стола ко мне подошли пять профессоров, они бы;

и возмущены некорректностью моих вопросов на собеседовании и пытались убе дить меня, что понимание работы RSA исключительно важно. Я же стоял на сво ем: рассказать на экзамене о деталях механизма RSA проще простого, а интерес но это лишь очень небольшому кругу1 людей. Кроме того, ответ экзаменуемого легко оценить по шкале «верно — неверно»;

а вот умение справляться с опасностями и атаками — штука существенно более сложная, и его вряд ли «измеришь* одш;

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

Но вернемся к Windows Security Push. Мы поняли, что необходимо обуча гь сотрудников построению безопасных систем, потому что в школе этого не пре подают. Мы осознали, что многие знают, как работает Kerberos, DES (Data Encryption Standard) и RSA, но этому знанию грош цена в базарный день, если человек ни когда не видел, как выглядит переполнение буфера в C++! Я часто повторяю: «Нель 1я знать того, чего не знаешь*, то есть если разработчик не знает, как делается безо пасный продукт, клиент никогда не получит защищенное приложение. Вот поче му нашей команде пришлось провести обучение 8500 сотрудников.

Сухой остаток таков: обучение методам безопасности необходимо, тем более, что ситуация в области защиты быстро меняется, так как обнаруживаются новые источники опасности. Поговорка: «То, что не известно, не может навредить*. — в области защиты попросту не работает. Неизвестное может обезоружить (и очень вероятно, что так и выйдет) ваших клиентов перед серьезной опасностью. Курсы по защите следует сделать обязательными для всех работников (как в Microsofl), Безопасность приложений сегодня 24 Часть I Это особенно важно для новых сотрудников. Не следует полагаться на то, что но вички что-то знают о безопасности систем!

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

Внимание! Обучение исключительно важно для того, чтобы создавать безо пасные системы. Не ждите, что люди знают, как проектировать, програм мировать, тестировать, документировать и развертывать безопасные системы;

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

Отношение сотрудников к обязательному обучению Мы ожидали, что принудительные занятия не понравятся сотрудникам и прием окажется прохладным, но мы ошиблись! В чем причина? Большинство компаний разработчиков ПО кишмя кишат энтузиастами информационных технологий, ко торых хлебом не корми — дай узнать что-то новое. А если занятие посвящено та кой «горячей» теме, как безопасность, то из аудитории их не выгнать. Так что дайте своим ИТ-фанатам информацию, которой они жаждут.

Примечание Раз уж мы заговорили об энтузиастах, не стоит недооценивать их стремление к первенству среди себе подобных. Большинство фанатов страстно увлечены своим делом и не прочь померяться силами, выяс няя, кто напишет самый быстрый, самый функциональный или самый маленький по объему код. Такие соревнования следует поощрять. Вот мой любимый пример «из жизни»: программист из команды по разработке сервера IIS 6 поклялся отдать свой талисман — гипсовую копию своего мизинца — тому, кто найдет дыру в его коде. Многие пытались, но, увы, никто не преуспел — приз никому не достался. Вы думаете, этот програм мист развлекался, объявляя награду? Конечно же нет;

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

Активный подход к безопасности при разработке приложений ГЛАВА 2 Непрерывность обучения Это печально, но истина в том, что каждую неделю появляются новые методы пли модификации старых способов взлома, которые делают ранее безопасные про граммы уязвимыми для атак. По этой причине обучение разработчиков следует проводить непрерывно. В частности, в нашей команде мы это делаем ежемесяч но: знакомим сотрудников с самыми свежими проблемами в области защиты, причинами возникновения проблем и способами смягчения последствий или полного устранения опасности. Мы также приглашаем гостей, которые расска tbi вают о своем опыте защиты систем.

Развитие науки о безопасности Оказывается, обучение безопасности имеет интересный побочный эффект. Изу чив основы, специалисты в конкретных предметных областях (а работая над Windows, мы имели дело с создателями файловых систем, специалистами в обла сти локализации, HTTP, XML и др.) начинают задумываться о том, как злоумыш ленники могут воспользоваться уязвимостью той или иной подсистемы (рис. 2 2), До обучения основам безопасности После обучения основам безопасности Рис. 2-2, Изменение отношения сотрудников к проблемам безопасности после обучения основным принципами защиты Акценты смещаются, актуальной становится придуманная на ходу поговорка:

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

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

Безопасность приложений сегодня 26 Часть I Внимание! Обучение безопасности преследует две цели. Во-первых, познако мившись с основами защиты, люди получают возможность контролиро вать создание программы, а также находить и устранять недостатки за щиты, Но вторая и самая главная цель — научить сотрудников не созда вать дыры в защите продукта с самого начала!

Образование позволяет избавиться от заблуждения, что «лишняя пара глаз — всегда лучше» Я много раз слышал утверждение, что чем больше глаз изучают код. тем больше брешей удается найти и тем безопаснее код. Это вопиющее заблуждение! Люди, анализирующие код, должны знать и понимать, как выглядят уязвимые места.

Приведу аналогию. Написание книги совпало с периодом громких разоблачений компаний, занимавшихся фальсификацией финансовой отчетности. Представьте себе, что исполнительный директор одной из таких компаний отвечает в Конг рессе США на вопросы, касающиеся учетной политики:

Представитель конгресса: У нас есть информация, что ваша компания представ ляла «липовые» отчеты.

Директор компании: Это неправда.

Представитель конгресса: Как вы можете это доказать?

Директор компании: Более 10 000 человек изучали наши отчеты, и ни один не нашел даже малейшего недостатка.

Представитель конгресса: Но каков уровень знаний этих «аудиторов» в облас ти финансов? Где они получили бухгалтерское образование и знакомы ли им особенности учета в вашей отрасли?

Директор компании: Какая разница? Ведь 10 000 человек — это 10 000 пар глаз!

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

В 2001 г. я поставил простой эксперимент, желая подтвердить мою теорию о роли обучения основам безопасности. Я обратился к двум моим знакомым: оба были технически подкованы и прекрасно разбирались в программировании. Я попро сил каждого проанализировать 1000 строк реального, взятого из Интернета от крытого кода на С и попытаться обнаружить в нем бреши. Первый "подопытный» нашел 10 недостатков, второй — 16. Затем я прочитал им часовую лекцию с де монстрацией массы реальных примеров программистских ошибок, которые вы лились в дыры в защите, и рекомендациями, как следует относиться к данным, поступающим в программу. Закончив, я попросил их проанализировать код сно ГЛАВА 2 Активный подход к безопасности при разработке приложений ва. Вы мне не поверите, но первый испытуемый нашел еще 45, а второй — 41 бреюсь.

Кстати, я сам обнаружил в программе только 54 недостатка. Таким образом, в общем зачете первый нашел 55 ошибок, т. е. на одну больше, чем я, а второй — 57, то есть еще две в придачу к нашим!

Если так очевидно, что обучение позволяет разработчикам быстрее и качествен нее распознавать недостатки защиты, то почему же люди продолжают верить, что нетренированные глаза и мозг способны повысить безопасность ПО?

Внимание! Горстка специалистов принесет больше пользы, чем армия неучей.

Интересный побочный эффект повышения образования персонала в области безопасности заключается в том. что разработчики узнают, куда обращаться nj )И затруднениях, и не мучаются, повторяя одни и те же ошибки. Об этом свидетель ствует вал вопросов, поступающих в корпоративные новостные группы и спис си почтовой рассылки в Microsoft. Люди задают осмысленные вопросы, потому ч::о начинают понимать что к чему. Кроме того, образуется критическая масса сотруд ников, которые точно знают, что требуется для проектирования, разработки, те стирования и документирования безопасных систем, и эти люди положительно вс is действуют на остальных. Так удается снизить риск появления новых брешей в ко, (е.

Сотрудников необходимо обучать безопасности! Эти знания не должны ост а ваться уделом элиты;

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

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

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

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

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

Помните, что не стоит выяснять знание мельчайших деталей тех или иных технологий. Я уже говорил, что владение основами безопасности — это не столько Безопасность приложений сегодня 28 Часть I знание механизмов обеспечения безопасности, сколько умение грамотно приме нять их для защиты реальных систем, На собеседовании я нередко пишу на доске отрезок кода и предлагаю канди дату найти место, в котором возможно переполнение буфера. Да. это узкоспеци альная задача, но программист должен безошибочно распознавать такую опасность.

Примечание Намного подробнее о переполнении буфера рассказывается в главе 5.

А вот еще одна любимая мной задачка:

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

• как введение устройства скажется на неприкосновенности частной жизни:

• как «обмануть» устройство;

• как предотвратить жульничество со стороны недобросовестных автовладельцев;

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

• кто должен программировать (записывать секретный код) устройство? Мож но ли доверять этим людям? Как решить эти проблемы?» Думаю, это очень полезный пример, потому что он помогает мне выяснить, как кандидат подходит к решению проблем безопасности. Причем задачка не прсд пола! ч ает глубоких знаний конкретных технологий. Рискуя повториться, не пере стану убеждать вас, что самое важное для создания безопасных приложений — правильный подход к решению проблем защиты. Можно объяснить человеку по дробности работы тех или иных технологий, но очень трудно изменить образ мышления, переориентировать его на безопасность. Принимайте на работу со трудников с «хакерскими» наклонностями.

С другой стороны, вам пригодятся и люди с «механистическим» мышлением — те, кто способен выявлять неудачные проекты и указывать, как их следовало де лать с самого начала. «Хакеры* зачастую не способны предложить способ реше ния, удовлетворяющий всех на предприятии с огромным числом клиентских ком пьютеров и серверов. Не нужно много ума, чтобы забраться в автомобиль и уг нать его, а вот чтобы спроектировать устойчивую к взлому машину и эффектив ную сигнализацию, потребуется квалифицированный механик или инженер. По этому нужны как *хакеры», так и «механики»!

Определите цели защиты продукта Сразу определяйте крут потенциальных клиентов и их требования к безопаснос ти. У моей жены и у сетевого администратора большой корпорации с отделени ями в десятках стран требования к безопасности сильно различаются. Я достаточно хорошо представляю, что необходимо жене, но пожелания крупного корпоратив ного клиента останутся большой загадкой, если вы их тщательно не соберете и ГЛАВА 2 Активный подход к безопасности при разработке приложений не проанализируете. Итак, кто же ваши клиенты и что они хотят? Если вы знако мы с ними, расспросите их, что опи вкладывают в понятие безопасности сие те мы. Каждый сотрудник, работающий над созданием продукта, должен в обязатель ном порядке знать потребности пользователей клиента. У нас в Microsoft мы об наружили, что создание образа будущего клиента позволяет лучше представить себе его возможные действия. Создайте красочные и живые психологические пор 1реты своих будущих пользователей (рис. 2-3) и развесьте их на стенах офиса. Ана лизируя цели клиентов в области безопасности, учитывайте демографические ха рактеристики, роли тех или иных пользователей в процессе работы или игры, их отношение к защите и допустимый уровень риска.

ты можем ему помо Рис. 2-3- Плакат с психологическим портретом будущего пользователя Часть I Безопасность приложений сегодня Определение круга потенциальных клиентов и целей по защите приложения позволяет предотвратить его «распухание», то есть бессмысленное перенасыще ние продукта ненужными функциями. Постоянно спрашивайте себя: «Действитель но ли эта функция защиты избавляет от опасности, которой боится будущий пользователь?» Если нет, советую хорошенько подумать — может, от нее вообще стоит отказаться. Ответьте на несколько вопросов и запишите ответы в специаль ный документ.

• Какова целевая аудитория приложения?

• Что означает «безопасность» для этой аудитории? Различается ли отношение к этому понятию в разных группах будущих клиентов? Разнятся ли требова ния по безопасности у различных пользователей?

• В какой среде будет работать продукт: в Интернете? в среде, защищенной бран дмауэром? на мобильном телефоне?

• Что вы хотите защитить?

• Каковы последствия компрометации защищаемых вашим приложением объектов?

• Кто будет управлять продуктом — пользователь или ИТ-администратор компа нии?

• Какие уже имеющиеся сервисы безопасности операционной системы и ИТ среды можно использовать в приложении?

• Как защитить пользователя от его собственных ошибок?

Вот что говорится о важности понимания бизнес-требований в документе ISO 17799 «Information Technology — Code of practice for information security mana gement* («-Информационная технология — Свод правил по управлению инфор мационной безопасностью») — международном стандарте, определяющем орга низационные, физические, коммуникационные и системные политики безопас ности при разработке ПО, — во введении и подразделе 10.1.1 раздела 10.1 «Security requirements of systems» («Требования к безопасности систем»):

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

Примечание ISO 17799 — очень общий документ, который в лучшем случае дает лишь основные правила разработки, но и он весьма помогает сообще ству разработчиков. Текст стандарта можно приобрести на сайте www.iso.cb.

Примечание Для сотрудников, работающих в компаниях, где руководствуют ся стандартом ISO 17799, замечу, что большая часть этой книги относится к разделам §9-6 «Application access control» («Управление доступом в приложениях»), §10.2 «Security in application systems» («Безопасность в прикладных системах*) и в меньшей степени — к разделу §10.3 «Crypto graphic controls» («Криптографические процедуры»).

Активный подход к безопасности при разработке приложений ГЛАВА Рассматривайте защиту как неотделимую функцию программы Защита — это такая же функция системы, как и остальные. Не относитесь к ней, как какому-то туманному и загадочному аспекте разработки приложения. И ни когда не относитесь к безопасности, как к фоновой задаче, которую можно отло жить на потом или выполнить в более удобное время. Безопасность следует рас пространить на все приложение. Позаботьтесь, чтобы описание каждой функции в спецификации программы содержало раздел с описанием влияния, которое оказывает данная функция на защиту приложения. С примерами учета последствий для безопасности вы можете познакомиться на сайте www.ietf.org, в каждой части любого из RFC-доку ментов, созданных группой IETF в последние годы, есть раз делы, посвященные безопасности, Помните: даже не предназначенные для защиты программы должны «уме гь» противостоять атакам. Вот несколько примеров:

• переполнение буфера в Microsoft Clip Art Gallery, позволяющее злоумышлен нику исполнить свой код (imimmicrosoft.com/techmt/security/buUetm/MSOO-015 аф)\ • изъян в ufsrestore, утилите для восстановления файлов для Solaris, который позволял рядовому локальному пользователю получать доступ уровня root (online.securityfocus.com/advisories/3621);

• команда сортировки son во многих UNIX-системах, в том числе Apple OS X, создает условия для проведения успешной DOS-атаки (ivww.kb.cert.org/vuls/id/ 417216}.

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

Примечание Мне очень нравится история, которую рассказал один мой друг.

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

оказалась весьма простой: по вечерам воскресенья вице-президент смот рел очередную «страшилку про хакеров-> — «Сеть» (The Net), «Тихушни ки» (Sneakers) или «Хакеры» (Hackers)!

Как-то мне пришлось анализировать программу, план разработки которой выглядел так:

• этап 0: создание проекта системы;

• этап 1: программирование базовых функций;

• этап 2: программирование дополнительных функций;

• этап 3: обеспечение защиты;

• этап 4: устранение ошибок;

• этап 5: поставка продукта.

Как вы думаете, действительно ли разработчики серьезно относятся к безопас ности? Я познакомился с этой командой только по инициативе тестировщика, который оказался рьяным энтузиастом безопасности и добился, чтобы меня п эй Безопасность приложений сегодня 32 Часть I гласили в качестве эксперта. Но в команде полагали, что сначала нужно реализо вать функции приложения и лишь затем решать вопросы безопасности. Огром ный недостаток такого подхода в том, что защита, реализуемая па этапе 3, впол не может свести на нет часть или вето работу, выполненную на этапах 1 и 2. Кро ме того, сложно удалить хотя бы часть «жучков», обнаруженных на этапе 3, в ре зультате чего программа останется уязвимой.

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

Помните, что, не реализуя безопасность с самого начала, вы столкнетесь с проблемами;

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

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

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

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

Внимание! Не добавляйте защиту вдогонку!

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

Недавно меня попросили посмотреть график разработки, и, должен признаться, я был очень приятно удивлен, увидев такое, ГЛАВА 2 Активный подход к безопасности при разработке приложений "••••• *ч""г*гпгр1Т|11рппппУ1Т1а1гя1й*ЕГ11111 и и ицгптип Этап Дата Мероприятия по обеспечению безопасности 0 1.09.2002 Начало проекта Обучение команды основам безопасности 08.09.2002 Этап 1: Начало 22.10.2002 День, посвященный защите, или День безопасное] 30.10.2002 Этап 1: Готовый код Завершение создания моделей опасностей.

грозящих системе 06.11.2002 1-й сеанс исследования защиты, проводимый совместно с группой Secure Windows 18.11.2002 День безопасности 27.11.2002 Этап 2: Начало День безопасности 15.12. Этап 2: Готовый код 10.01. День безопасности 02.02. 2-й сеанс исследования защиты, проводимый 24.02. совместно с группой Secure Windows Устранение ошибок защиты первого и второго Первая бета-версия 28.02. приоритетов Первая бета-версия:

07.03. окончательный вариант (Release) День безопасности 03.04. Этап 3^ Готовый код 25.05. Начало 4-недельной «работы нал безопасностью 01.06. 3-й сеанс исследования защиты, проводимый 01.07. совместно с группой Secure Windows Вторая бета-версия:

14.08. окончательный вариант (Release) День безопасности 30.08. Первый кандидат 21.09. па выпуск (Release Candidate) Заключительный, 4-й сеанс исследования защит;

а.

проводимый совместно с группой Secure Windows Поставка приложения!

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

Безопасность приложений сегодня 34 Часть I Защита тесно вплетена в процесс, и члены команды заботятся о безопасности с самого начала его разработки. Выделять достаточно времени для работы над безопасностью очень важно.

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

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

Примечание Не забудьте предусмотреть в графике время на обучение, Моделируйте опасности, грозящие системе Моделированию опасностей посвящена вся глава 4, но пока мы лишь скажем, что модели возможных опасностей следует закладывать в основу спецификации про екта. Без них вы просто не создадите качественный продукт, так как для постро ения адекватной защиты надо понимать, что грозит приложению. Знайте: на со здание моделей придется потратить немало времени. Но они стоят того, С самого начала запланируйте процедуру удаления функций, оказавшихся небезопасными «ПО никогда не умирает — оно переходит в разряд опасных программ*. Повесьте это изречение на видном месте и никогда не забывайте, потому что оно верно, ПО не изнашивается, как это происходит с материальными вещами, но оно мо ментально становится крайне опасным, когда выясняется его неспособность про тивостоять атакам нового типа. Именно поэтому следует заранее планировать процесс удаления устаревших функций. Например, постепенно выводить из об ращения старую функцию, заменяя ее более безопасной версией. Это даст время, необходимое для плавного перевода клиентов на обновленное и безопасное при ложение. Обычно клиенты очень не любят неожиданностей, но. спланировав и предупредив их об обновлении заранее, вы подготовите их к переменам.

ГЛАВА 2 Активный подход к безопасности при разработке приложений Определите допустимое число ошибок Решая, какие «жучки» следует искоренить до начала поставок продукта, оставай тесь реалистом и прагматиком. В идеале все проблемы ПО, в том числе дефе*ты безопасности, следует устранять до поставки продукта клиенту. Но в реальности все не так просто. Защита — всего лишь одна, хотя и очень важная, часть прило жения, и при ее создании приходится жертвовать чем-то или идти на компромиссы.

Решая, как устранить конкретный недостаток, приходится учитывать множес" во других факторов, число которых практически неограничено, но основные — ве роятность регрессионных ошибок, доступность для людей с ограниченными возможностями (инвалидов), особенности развертывания, локализация, произ ю дительность, стабильность и надежность, масштабируемость, обратная совмести мость и простота поддержки и сопровождения.

Некоторым это может показаться кощунством, по следует смириться с тем, что никому не дано создать идеальное ПО (если, конечно, не рассматривать тот иа риант, когда заказчик готов вложить в него несколько миллионов долларов). 1-ю лее того, даже если вы попытаетесь разработать безупречное приложение, на его создание придется затратить столько времени, что оно безнадежно устареет ta долго до выхода в свет. Программа должна делать именно то, для чего ее создали, не больше и не меньше. Это не значит, что она в принципе не «падает*, — это означает, что при сбое она никоим образом не открывает систему для атаки, Примечание До прихода в Microsoft мой начальник работал в одной малень кой секретной группе, которая разрабатывала систему, удовлетворяющую требованиям безопасности класса A l Orange Book. («Оранжевая книга* применяется Министерством обороны США для оценки надежности за щиты систем, а класс А1 — это очень высокий уровень безопасности.

Подробности — на сайте http://wnnv.cfynamoo.com/orange.') Создание этой, исключительно безопасной, системы заняло массу времени, и хотя она действительно обеспечивала требуемую защиту, проект пришлось за крыть, так как ко времени его завершения система безнадежно устарела и оказалась никому не нужной.

Исправлять следует те ошибки, искоренение которых оправдано. Как вы дум а ете, стоит ли устранять дефект, который повлияет на работу лишь 10 пользовате лей из клиентской базы общей численностью 50 000 пользователей, создаст очень небольшую опасность, потребует серьезной перестройки архитектуры, что в CBI >ю очередь породит длинный хвост регрессионных ошибок и нарушит работу по ловины пользователей? Наверняка лучше исправить недостаток не в текущей,.t в следующей версии;

кроме прочего это вам даст время, чтобы предупредить KI и ентов о грядущем изменении заранее.

Pages:     || 2 | 3 | 4 | 5 |   ...   | 12 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.