В наихудших случаях руководители подразделений, пытаясь продвинуться вперед, обмениваются «бродячими» группами программистов, как пятиклассники — коллекционными карточками покемонов. Понятно, что ничего хорошего в этом нет.
Разрыв между разработкой ПО и обеспечением безопасности привел к тому, что при создании программного обеспечения почти не учитываются современные технические риски. Сложные и сильно связанные вычислительные среды подвергаются бесчисленным угрозам, и разработчики ПО, игнорирующие проблемы защиты, фактически гарантируют, что их творения будут иметь очень много уязвимостей. Для повышения уровня безопасности программного обеспечения в процессе его разработки следует использовать знания организаций, профессионально занимающихся информационной защитой.
Необходимость сближения
Передовые методы повышения уровня программной безопасности состоят из обозримого числа простых действий (см. рисунок). Они должны начинаться на самых ранних стадиях процесса разработки и продолжаться в ходе развертывания и эксплуатации программного обеспечения. Все больше организаций и отдельных разработчиков принимают эти методы на вооружение, но им часто не хватает жизненно важных знаний в области защиты. А знания накапливаются в ходе многолетних наблюдений за вторжениями в программные системы, ликвидации их последствий, постоянной борьбы с хакерами и т.д. Без такого опыта разработчики при всем желании не могут учитывать все «дыры», уже обнаруженные в сходных прикладных архитектурах. Авторы недавно появившихся книг [1,2] потихоньку начали заполнять этот пробел в знаниях, но наука о нападениях на программные системы еще полна белых пятен.
В свою очередь, специалисты по информационной безопасности (по уязвимостям, заплатам и ликвидации последствий компьютерных инцидентов) провели годы в борьбе со злоумышленниками, нападающими на реальные системы. Они до мельчайших подробностей изучили слабые места многих программ и связанные с ними профили атак. Однако среди них не так уж много профессиональных программистов, а потому они склонны ограничивать свой арсенал такими методами противодействия, как установка программных заплат и брандмауэров, обновление баз данных сигнатур вторжений и т.п. И очень редко специалисты по безопасности бывают вовлечены в важный программный проект.
Печально, что два сообщества высококвалифицированных технических экспертов существуют бок о бок в полной изоляции, хотя обмен знаниями и опытом мог бы привести к их взаимному обогащению.
Методы разработки безопасного ПО
Мы не сможем описать все методы разработки безопасного программного обеспечения, но постараемся в общих чертах обрисовать самые эффективные из них.
Разработка требований: сценарии злоупотреблений
Концепция сценариев злоупотребления (abuse case) опирается на метод разработки на базе сценариев использования (use case). В сценарии злоупотребления разработчик описывает преднамеренно неправильное применение программного обеспечения, а потом обдумывает его последствия. Например, можно построить ряд сценариев злоупотребления, которые будут достаточно подробно описывать возможные атаки (переполнение буфера ввода, внедрение в программу вредоносных данных и т.д.) и реакцию ПО на эти действия. Как происходит и со сценариями использования, каждый сценарий злоупотребления порождает определенные требования к программе и сценарий ее испытания.
Проектирование: анализ бизнес-рисков. Оценка того, как может повлиять на бизнес компрометация программной системы, — дело жизненно важное. Если этой проблеме не уделять серьезного внимания, анализ защиты потеряет всякий смысл. При качественном анализе рисков потери организации, финансирующей разработку проекта, рассматриваются с точки зрения как прямых убытков (ответственность за ущерб, снижение производительности, затраты на переделку), так и косвенных (потеря репутации и дискредитация торговой марки).
Проектирование: анализ архитектурных рисков. Как и при анализе рисков для бизнеса, при анализе архитектурных рисков оцениваются технические уязвимости проектируемого приложения и их возможное влияние на бизнес. Для получения высокоуровневого описания проекта аналитическая группа рассматривает каждый модуль, интерфейс, взаимодействие и т.д. с точки зрения известных методов нападения и вероятности их успеха. Чтобы составить низкоуровневое представление о безопасности программной системы, аналитики наряду с целостным проектом обычно исследуют и его компоненты. Важен единый подход к защите: по крайней мере, половину ее дефектов естественным образом порождает архитектура.
Планирование испытаний: проверка функций защиты. При разработке сценариев и планов испытаний тестировщики используют функциональные требования и спецификации. И точно так же при разработке тестов, позволяющих проверить функции безопасности программного обеспечения, нужно опираться на специфические требования к защите. Обычно испытываются функции шифрования, идентификации пользователей, входа в систему, конфиденциальности, проверки подлинности и т.д. Это так называемые «положительные» функции защиты «хороших парней».
Планирование испытаний: проверка устойчивости к нападениям. Выступления в роли «хорошего парня» недостаточно: вы должны надеть черную шляпу и начать думать как «плохой парень». Сценарий проверки устойчивости к нападениям — естественный результат оценки и определения приоритетов архитектурных рисков. Все архитектурные риски и сценарии злоупотребления должны быть описаны и задокументированы вплоть до нижнего уровня. Требуется подробно объяснить, как именно нападающий может скомпрометировать программную систему, используя ее недостатки. Такие описания помогут составить список сценариев для последующего «враждебного» тестирования.
Реализация: проверка кода. Предыдущие действия направлены на выявление архитектурных недостатков программного проекта, но при их выполнении полностью игнорируются возможные ошибки кодировщиков, то есть ошибки реализации. Они возникают в изобилии, и к их числу можно отнести печально известное переполнение буфера из-за использования уязвимых интерфейсов прикладного программирования (API) или неправильного применения таких интерфейсов. Проверка кода — как ручная, так и еще более важная автоматизированная (осуществляемая с помощью статических инструментов)— помогает идентифицировать ошибки защиты еще до выпуска программного обеспечения.
Тестирование системы: попытки вторжения. Правильно организованные тестовые вторжения в систему позволяют выявить человеческие и процедурные ошибки, сделанные при конфигурировании и развертывании программного обеспечения. Образцовые испытания проводят на основе предварительно выявленных рисков: в таких случаях удается непосредственно исследовать уязвимые места и устанавливать степень их «привлекательности» для злоумышленников.
Сдача системы: развертывание и эксплуатация. Тщательные конфигурирование и настройка среды развертывания программного приложения позволяют значительно повысить уровень его безопасности. Создание удобной среды развертывания начинается на сетевом уровне, продолжается на уровне операционной системы и заканчивается установкой и конфигурированием функций защиты приложения.
Рекомендации по применению
Рассмотрев методы разработки безопасного программного обеспечения, вернемся к главному вопросу: какую пользу в случае применения таких методов могут принести специалисты по защите? Если вы — сертифицированный специалист по безопасности информационных систем или сетевой администратор, то этот раздел — для вас. Мы вернемся к уже рассмотренным методам, чтобы дать некоторые рекомендации разработчикам программного обеспечения и практикам в области информационной защиты.
Сценарии злоупотреблений. Привлечение специалистов по информационной безопасности к разработке сценариев злоупотреблений — шаг довольно очевидный. Практики садятся за общий стол, вооруженные опытом многолетних наблюдений, данными о нападениях, навыками ведения следствия [3], профилей атак и т.п. Печальный опыт часто делает их неприветливыми, зато они знают врага в лицо.
Анализ сценария злоупотреблений нередко начинается с «мозгового штурма». Группа разработки описывает сценарии использования и функциональные требования к приложению, в то время как эксперты с важным видом рассуждают о том, как злоумышленник может надругаться над этим приложением. Достойное участие в обсуждении предполагает тщательное рассмотрение похожих систем и «удачных» нападений на них. Для успешного анализа сценария злоупотреблений очень важно выйти за пределы собственного опыта, поэтому рассмотрите и другие области, которые могут иметь отношение к вашему приложению.
Повторяем, очень важен реальный «боевой» опыт. Специалисты по безопасности, вероятно, обнаружат (к их немалому удивлению), что программисты находятся в блаженном неведении относительно многих форм нападения, ежедневно встречающихся за периметром сети. Естественно, зачастую «неведающие» являются и неверующими. При убеждении этих скептиков старайтесь избегать преувеличений: нет ничего хуже высокомерного «безопасника», с чувством собственного превосходства вещающего о пустяках. Не переоценивайте опасность изученных вами нападений — просто придерживаетесь фактов и будьте готовы подкрепить любой тезис примерами из практики. Дополнительным преимуществом окажется ваше знакомство с программными технологиями.
Анализ бизнес-рисков. При оценке бизнес-рисков, связанных с программным обеспечением, нужно, прежде всего, проконсультироваться с самими бизнесменами. Это хорошо понимают в организациях, уже практикующих анализ технологий на бизнес-уровне (к сожалению, техническая оценка бизнес-ситуации обычно не доходит до уровня программного обеспечения). Стандартный подход легко расширить с помощью нескольких дополнительных вопросов. Каково представление заказчиков о безопасности? Каковы их ожидания? Какие их намерения может сорвать успешное нападение? Что их беспокоит в области защиты?
Ценность ответов специалистов по безопасности на такие вопросы зависит от богатства их личного опыта. Другими словами, они должны опираться на собственный анализ нарушений защиты аналогичных бизнес-приложений. Тот же опыт позволяет им со знанием дела ответить на несколько других вопросов. Затраты каких типов понесли аналогичные компании в связи с нападениями? Каким бывает время простоя? Последовала ли публичная огласка в каждом случае? Была ли запятнана репутация предприятий? Специалисты по безопасности могут сопроводить свои ответы примерами, но в этом случае также важно не преувеличивать факты. Ссылаясь на инциденты в других организациях, будьте готовы подкрепить любое заявление новостными сообщениями и другими документами из независимых источников.
Анализ архитектурных рисков. Теперь мы переходим к технической сути процесса разработки программного обеспечения. Для эффективного анализа архитектурных рисков специалисты по безопасности должны обладать разносторонней технической эрудицией, охватывающей как само приложение, так и его основообразующие платформы, структуры, языки, функции, библиотеки и т.д. Понятно, что самым полезным членом группы информационной защиты будет эксперт по технологиям с солидным опытом применения конкретных программных инструментов. Он сумеет обеспечить «обратную связь» процесса разработки с реальным миром.
Например, если аналитическая группа обсуждает достоинства и недостатки конкретного сетевого протокола шифрования, то специалист по информационной безопасности поможет шире взглянуть на предмет обсуждения. Все программы имеют потенциальные недостатки, но были ли реальные нападения на компонент X? Известны ли уязвимости протокола, который планируется использовать в проекте? Является ли коммерчески доступный компонент или платформа постоянным объектом нападений либо имеет безупречную репутацию? И сколько уязвимостей этого объекта и соответствующих случаев нападения уже известны? Такого рода обратная связь чрезвычайно полезна для того, чтобы упорядочить риски и недостатки по приоритетам и выбрать стратегии противодействия.
Планирование испытаний. Хотя планирование и проведение испытаний обычно являются прерогативами группы проверки качества (quality assurance, QA) и группы разработки, специалист по информационной безопасности может внести полезный вклад и в эти процессы. Тестирование (особенно на предмет подверженности рискам) должно не только охватывать все функциональные возможности, ни и довольно точно воспроизводить возможные шаги злоумышленника при взламывании системы. Реалистичные сценарии нападения гораздо полезнее полностью придуманных «атак». Если организации, занимающиеся традиционными тестированиями, и могут принести хоть какую-то пользу, то лишь при планировании и проведении испытаний на основе функциональных спецификаций. Разработка сценариев для тестов подверженности рискам представляет собой существенное отступление от традиций и должна базироваться на опыте специалистов по безопасности. И наиболее ценными оказываются специалисты, способные «думать за противника».
Проверка кода. Очевидно, что проверка кода требует его знания. Специалист по безопасности, не имеющий большого опыта программирования, приносит не слишком много пользы. Если вы не знаете, как ведет себя переменная или как влияют на аргумент метода атрибуты static и final, бесполезно целыми днями глазеть на тексты программ. Поэтому выполнение такой проверки лучше оставить организации-разработчику, особенно если она располагает современными инструментами анализа исходного кода. На этапе проверки кода опыт специалиста по безопасности находит применение лишь в тех случаях, когда этот специалист хорошо разбирается в языках программирования и умеет устранять уязвимости на уровне кода.
Это утверждение может вызвать удивление в тех организациях, которые пытаются повысить уровень безопасности своего ПО силами отдела информационной защиты. Повторяем: хотя идея укрепления защиты сама по себе бесспорна, для ее успешной реализации на уровне кода необходим практический опыт программирования. Отдел информационной безопасности не может давать содержательных советов кодировщикам, располагая лишь сканером исходного кода.
Испытания на вторжение. Испытания программного обеспечения на соответствие функциональным спецификациям традиционно были делом групп проверки качества. А испытания на вторжение — обычно сфера деятельности групп информационной безопасности и организаций, занимающихся расследованиями и ликвидацией последствий компьютерных инцидентов. Поэтому привлечение к таким испытаниям специалистов по информационной безопасности является вполне естественным.
Разумеется, нельзя не учитывать некоторых тонкостей. Сегодня в большинстве испытаний на вторжение основное внимание уделяют топологии сети, размещению брандмауэров, коммуникационным протоколам и т.п. При таком «внешнем» подходе сами приложения почти не затрагиваются, но испытания должны включать в себя и подход «изнутри наружу», то есть анализ рисков и других составляющих программной безопасности. Различие между «внешним» и «внутренним» подходами иногда описывают как различие между «испытанием на вторжение в сеть» и «испытанием на вторжение в приложение». Для обеспечения безопасности ПО последнее значительно важнее.
Следует отметить ценность инструментов вторжения, построенных по принципу «черного ящика». Чрезвычайно полезны сканеры сетевой безопасности, такие как nessus, nmap, SATAN и т.п., позволяющие обнаруживать ошибки конфигурирования сложных сетей и сетевых сервисов. Сканеры безопасности приложений далеко не так полезны, и если под «тестом на вторжение в приложение» вы подразумеваете использование именно такого инструмента, вам придется пройти длинный путь. Излишне говорить, что набор стандартных тестов, сколь бы обширным он ни был, не позволяет провести полноценные испытания программного обеспечения. Нелепо надеяться на то, что функционирование любой программы можно проверить с помощью тестов, составленных еще до того, как эта программа была задумана. Столь же нелепа и мысль о проверке безопасности произвольной программы с помощью стандартных тестов на обеспечение безопасности.
Хорошо уже то, что специалистов по информационной безопасности постепенно начинают привлекать к испытаниям на вторжение. Но для проведения эффективных испытаний эти специалисты должны хорошо разбираться в программном обеспечении.
Развертывание и эксплуатация. Многие разработчики возразят, что развертывание и эксплуатация ПО не имеют отношения к процессу его разработки. Но мы не справимся с проблемами развертывания и эксплуатации, если программное обеспечение построено очень плохо и разваливается на глазах, — вне зависимости от прочности фундамента, на котором мы его устанавливаем. Грубо говоря, эксплуатирующие организации долго мирились с плохим качеством ПО, и это сделало их осторожными.
Если мы намерены безопасно установить приложение в безопасной рабочей среде с целью его безопасной эксплуатации, то на этой работе, безусловно, положительно скажется участие специалиста по информационной безопасности. Особенно велика его роль в тонкой настройке контроля над доступом на уровне сети и операционной системы, а также в конфигурировании механизмов регистрации и мониторинга, наиболее эффективных при ликвидации последствий инцидентов. То, что нападения обязательно будут и что надо готовиться к устранению учиненного ими беспорядка, очевидно специалистам по информационной безопасности, поэтому так важно их участие на данном этапе.
Дело не для слабонервных
Даже если вы считаете наши рекомендации достойными внимания, помните, что увязка обеспечения информационной безопасности с разработкой ПО — дело не для слабонервных. Ключ к успеху — тесное сотрудничество с организацией-разработчиком. Если ее сотрудники воспримут специалистов по информационной безопасности как тайную полицию или как «людей с палками», которые время от времени больно бьют их неизвестно за что, вы получите серьезную проблему.
Но во многих случаях разработчики сами жаждут получить дельный совет от грамотного специалиста по защите. Беда лишь в том, что они не знают, кто может оказать реальную помощь, а кто является всего лишь хвастливым «чайником». И первый шаг специалиста по безопасности состоит в том, чтобы закатать рукава и предложить разработчикам свою помощь.
Как только вы убедите их в своей компетентности, постарайтесь еще немного продвинуться вперед. Вместо того чтобы попытаться одним гигантским усилием изменить мир, делайте всего лишь по шагу за раз. Будьте осторожны, чтобы вся система не рухнула под гнетом множества единовременных изменений.
Еще один необходимый шаг состоит в том, чтобы, не жалея времени, узнать как можно больше о разработке программного обеспечения вообще и о конкретной среде разработки. Изучите типы приложений, разрабатываемых партнерами-программистами, бизнес-цели этих приложений, используемые языки, инфраструктуры, платформы, библиотеки и т.д. Лучше указывать недостатки со знанием дела, чем с невежественным энтузиазмом. Программисты — не самые терпеливые люди на планете, и зачастую у вас есть лишь один шанс быть принятым в дело. Если сумеете помочь — отлично, но если помешаете, церемониться с вами не станут. В конце концов, успех проекта во многом зависит от личностных особенностей его участников. И, разумеется, даже самые лучшие намерения и самое тщательное планирование не гарантируют успеха.
Описанные нами меры защиты ;— это лишь верхушка айсберга передовых методов, но радует уже то, что такие методы вообще появляются. Естественно, дисциплина программной безопасности постепенно разовьется, а передовые методы изменятся, но некоторое время наши советы будут оставаться актуальными.
ЛИТЕРАТУРА
- G. Hogland and G. McGraw. Exploiting Software: How to Break Code. — Addison-Wesley. — 2004.
- J. Koziol et al. The Shellcoder?s Handbook: Discovering and Exploiting Security Holes. — John Wiley & Sons. — 2004.
- D. Farmer and W. Venema. Forensic Discovery. — Addison-Wesley. — 2004.
Кеннет Ван Вик (ken@krvw.com) — главный консультант KRvW Associates и директор по научно-исследовательской работе компании Cigital.
Гэри Макгроу (gem@cigital.com) — технический директор компании Cigital. Макгроу является соавтором нескольких книг по компьютерной безопасности, в том числе Exploiting Software (Addison-Wesley, 2004), Building Secure Software (Addison-Wesley, 2001) и Java Security (John Wiley & Sons, 1996).
Kenneth R. van Wyk, Gary McGraw, Bridging the Gap between Software Development and Information Security, IEEE Security and Privacy, September/October, 2005. IEEE Computer Society, 2005, All rights reserved. Reprinted with permission.
