Дао безопасности

Элементарная задача

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

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

Приведу простой пример.

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

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

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

Физик может оставаться физиком.

Итак, что мы имеем. Элементарные задачи решаются с применением известного, шаблонного способа. Есть соответствие задача — метод (шаблон) ее решения, причем в элементарном случае это соответствие однозначно. Думать не надо: как только мы распознали задачу, у нас есть информация, как ее решать.

Но не все всегда так просто.

Иерархия целей

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

Комплексные задачи мы решаем, разбивая их на подзадачи. Затем эти подзадачи могут быть снова разбиты на новые подзадачи, и так далее: мы создаем иерархию промежуточных результатов. Такой алгоритм достижения «сложной» цели, во-многом, определяется устройством нашего мозга (см., например, [Botvinick2008]), поэтому создание иерархии подцелей является очень общей стратегией. Разработка программного обеспечения не является исключением: мы последовательно используем несколько шаблонных решений для пошагового приближения к нашей цели.

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

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

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

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

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

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

С этой точки зрения, разработка приложений является последовательностью уточнений. Мы начинаем с самой абстрактной идеи, например, «нам нужен классный текстовой редактор». Затем эта идея проходит серию детализации, становясь, в конце концов, набором инструкций для компьютера, пользовательской документаций, методиками обучения пользователя.

Последовательность уточнений — тоже в определенной степени шаблон. Думаю, все эту последовательность легко назовут: разработка требований, разработка архитектуры, разработка локальной архитектуры и, наконец, разработка кода. Не все так просто: о многих сложностях создания программ и как их решают — шаблонных методах разработки — я говорил в другой своей статье «Когда „agile“ (не) к месту». В современных процессах эти этапы могут перекрываться, идти параллельно, могут происходить возвраты к уже сделанному; тем не менее логика связи идей, артефактов, создающихся на разных этапах, остается неизменной.

Из этих этапов несколько выделяется разработка требований. Она сама по себе состоит из нескольких подэтапов (см., например, [Pohl2010]); их, как минимум, два: выявление требований, и собственно разработку, создание идеи решения, которое бы удовлетворило бы запросы клиента.

«Забудем» сейчас про выявление требований. Логика этого этапа несколько отличается от всех остальных, и я немного скажу о нем в Приложении, в разделе «Исследование». То есть, на этапе «разработки» требований мы будем рассматривать только собственно их конструирование, считая, что мы уже понимаем запросы пользователя.

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

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

Разные этапы — разные шаблонные решения. Мы используем известные алгоритмы (причем, для каждой области деятельности есть свои собственные алгоритмы), шаблоны архитектуры (см., например, [Taylor2009], [Bass2012]), шаблоны дизайна программы (здесь нельзя не упомянуть классическую книгу «банды четырех» [Gamma1995]). Даже при кодировании мы используем идиомы, свойственные тому или иному языку программирования.

Например, пусть нам надо организовать цикл в программе на языке C. Думаю, мало программистов будут долго задумываться, они сразу напишут:

for ( int i=0; i<n; i++ )

Это шаблон организации цикла. И этот шаблон встроен в язык C: на уровне процессорных команд, вы знаете, все выглядит несколько иначе.

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

Обсуждение стратегии

Здесь я хочу сделать маленькое отступление и обратить особое внимание на когнитивную стратегию проектирования программного продукта.

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

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

Вернемся к примерам. Вы думаете, решив комплексную задачу, мы достигли максимума сложности? Это не совсем так.

Компромиссные решения

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

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

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

Безопасность — компромисс на всех этапах разработки.

В разработке приложений ситуация выбора — скорее закономерность, чем исключение. Необходимость принятия решений возникает на всех этапах жизненного цикла, однако, наиболее ярко эта необходимость проявляется при проектировании, когда решается, какими свойствами будет обладать программа. Так нам приходится решать, какие функции должна реализовывать программа, решать возникающие при этом конфликты, приоритезировать требования (см., например, [Pohl2010]). Кроме того, нам приходится решать, как наше приложение будет выполнять свои функции, какими качественными характеристиками оно будет обладать; например, насколько оно будет безопасным, насколько оно будет надежным, быстрым… И, конечно, многие качества противоречат друг другу, нам приходится делать выбор (см., например, [Bass2012]).

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

Однако, в основе большинства методов разрешения конфликтов лежит одна и та же схема.

В этой схеме можно выделить пять этапов.

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

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

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

Но и на объективной оценке все не заканчивается. Получив такую характеристику, мы должны оценить полезность полученного качества. А эта полезность связана с объективным измерением очень нелинейно, и, иногда, не очень очевидно (см., например, [Bass2012]).

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

Объективную оценку в этом случае получить достаточно просто: мы используем время реакции программы на полученные запросы.

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

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

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

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

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

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

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

Во-первых, разные участники проекта могут иметь разные интересы. Так непосредственный пользователь продукта и представитель отдела безопасности заказчика, очевидно, будут спорить о необходимой функциональности. Пожалуй, разница интересов — одна из самых часто встречающихся причин возникновения конфликтов, и поэтому методам нахождения компромисса в этой ситуации посвящено множество исследований и опубликовано немало литературы (см., например, [Masters2002]).

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

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

Поэтому не случайно выбор при наличии множества критериев привлекает пристальное внимание исследователей. Способов разрешить противоречия разработано множество, но, по моим наблюдениям, для этого очень часто используется метод «анализа иерархий», разработанный Томасом Саати (см., [Saaty1989]); возможно даже, он не просто «часто используется», а является самым популярным.

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

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

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

Заинтересовавшихся отправляю к специальной литературе. Для начала можно посмотреть, например, две книги, о которых я уже упомянул в начале этой части ([Pohl2010] и [Bass2012]).

Творческое решение

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

Вспомним, как мы искали компромиссное решение.

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

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

Причин может быть, как минимум, две.

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

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

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

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

А сейчас вернемся к творчеству.

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

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

Комплексность

Обеспечение корректности — сложная и комплексная задача. В ее решении можно выделить три взаимодополняющих направления (см., например, [Tian2005]):

• профилактика дефектов;
• обнаружение дефектов;
• изоляция дефектов.

Профилактика и обнаружение — технологии времени разработки. Говоря о безопасности, методы, применяемые на этом этапе, согласно iso 15408 необходимо описывать в разделе «Гарантии разработки».

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

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

Проверка решения

Обнаруживаются дефекты в ходе проверки решения.

Проверка решения при разработке — задача сама по себе комплексная. Чтобы убедиться в правильности полученных нами результатов, мы должны ответить на два вопроса ([Braude2000]): «Мы делаем правильную программу?» и «Мы делаем программу правильно?». Ответ на первый вопрос мы ищем в ходе валидации, на второй — в ходе верификации.

Мы ответили отрицательно на любой из этих вопросов? Значит мы нашли в нашей программе дефект.

Работа над ошибками

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

К сожалению, практика несколько расстраивает. Кто занимался программированием, знает шутливую (или не очень шутливую?) примету: «если программа компилируется с первого раза, значит она написана принципиально неправильно»?

Сейчас практически в любой новой программе находятся дефекты.

Но обнаружение дефекта — не самоцель. Очевидно, необходима работа над ошибками (хотя многие компании стремятся этого не делать).

Функциональность

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

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

Функциональность безопасности — тема очень обширная. Например, к вопросам функций следует отнести и модели безопасности ([Grusho1996], [Devaytin2005]), и методы аутентификации ([Smith2002]), и криптографические методы ([Schneier2002], [Grusho2000]), и методы анализа журналов событий ([Babbin2006]), и методики обнаружения сетевых атак ([Bejtlich2004]), и многое другое, что я сейчас даже не вспомню. Вообще, как мне кажется, эта сторона является самой изученной во всей тематике безопасности программного обеспечения, и литературы здесь действительно более чем достаточно. Заинтересованным читателям могу порекомендовать хороший обзор этой темы, мой любимый учебник по безопасности ([Bishop2003]).

Большое внимание функциям безопасности уделяется и в современных стандартах. Так в iso 15408 примерно половина всего документа посвящена именно функциональным свойствам «продукта информационных технологий».

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

Пользовательский интерфейс

У безопасности есть важный, но часто забываемый аспект. Чтобы наше приложение можно было безопасно использовать, оно должно иметь понятный и приемлемый для пользователя интерфейс (см., например, [Cranor2005]).

Некоторые специалисты относят пользовательский интерфейс к архитектуре программы (см., например [Bass2001]). Действительно, архитектура является носителем нефункциональных свойств приложения, и пользовательский интерфейс, очевидным образом попадает в эту категорию.

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

Архитектура

Безопасность — нефункциональное свойство программного обеспечения. Это заявление, конечно же, звучит несколько странно после того, как мы только что обсудили ее функциональные аспекты, но именно так рассматривают безопасность многие весьма уважаемые специалисты (см., например, [Bass2012] и [Taylor2009]). И если подумать, то можно прийти к выводу, что здесь есть своя логики: функции безопасности не делают ничего «полезного», они, скорее, предназначены для предотвращения незаконного использования другой функциональности программы; подробнее об этом вы можете почитать в другой моей статье.

Считается, что носителем нефункциональных свойств является архитектура. Упрощенно, под «архитектурой» программы можно понимать ее структуру; так, в частности, архитектура определяется частями, из которых состоит программа, свойствами этих частицей, и взаимодействием отдельных частей между собой. В частности, написана программа на C++ или на Jave — это описывается вместе с архитектурой приложения.

Безопасность должна быть отделена от бизнес логики.

Я уже писал о влиянии архитектуры на безопасность. Заинтересованному читателю порекомендую почитать посвященный этой теме раздел другой моей статьи (Качество и архитектура программы).

Приведу только небольшой пример оттуда.

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

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

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

Архитектурный аспект безопасности проработан относительно мало. Пока не существует стандартов безопасной архитектуры; тем не менее, уже давно — по меркам нашей индустрии — можно найти работы, которые описывают успешный опыт в этой области (см., например, [Kienzle2003], [Blakley2004], [Dougherty2009]).

Консерватизм

Безопасность является крайне консервативной областью. Действительно, прежде чем начать использовать то или иное шаблонное решение, специалисты долго его изучают, анализируют его уязвимости. Даже если новый шаблон на первый взгляд выглядит чрезвычайно защищенным, применять его на практике не спешат (отличается от поведения «программистов», особенно молодых?).

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

Такому консерватизму есть объяснение: обнаружение ошибок занимает много времени. Иногда уязвимости в алгоритме, шаблонном архитектурном решении, конкретной библиотеке обнаруживаются только через несколько лет, иногда совершенно (ну или почти) случайно.

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

Компромиссность

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

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

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

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

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

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

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

Еще раз. Безопасность — компромисс на всех этапах разработки приложения.

Постановка цели

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

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

Более того, наши «безопасники» часто вообще этот этап забывают. Внимательно почитайте любую статью наших «аналитиков», послушайте, что они говорят на вебминарах. Вы видели, чтобы кто-то из них говорил о постановке цели? В лучшем случае они приводят определение уязвимости, это, конечно, имеет некоторое отношение к нашим целям, но все же совсем не то. Например, попробуйте как-нибудь задать «аналитику» вопрос, какого объема анализа нашей программы достаточно, на каком этапе можно остановить поиск уязвимостей; как вы думаете, сможет он обоснованно на него ответить? Но этот вопрос — только один из множества, на которые необходимо найти ответ, чтобы получить четкое понимание целей разработки.

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

Решения-кандидаты

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

В зависимости от новизны ситуации, здесь возможны несколько вариантов:

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

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

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

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

Важно заметить: пока мы не выходили за рамки известных шаблонов.

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

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

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

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

Уникальное решение

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

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

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

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

Анализ уникального решения

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

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

Характеристики продукта сильно различаются по возможности их проверки.

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

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

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

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

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

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

Если нет, держитесь подальше от изобретательства в безопасности.

Оценка и выбор решения

К этому моменту уже мы знаем свойства всех решений-кандидатов. Нам осталось только «взвесить» эти решения и выбрать наилучшее.

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

После выбора решения мы можем переходить к его реализации.

Реализация шаблона

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

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

Проверка соответствия

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

Теперь мы должны проверить соответствие нашей реализации шаблону.

Здесь надо обратить внимание, у большинства шаблонов есть два аспекта. С одной стороны, шаблон — описание того, что и/или как должен делать программист (разработчик вообще) чтобы достичь своей цели; именно так мы чаще всего и воспринимаем наш шаблон. Но у большинства шаблонов есть и другая сторона: перечисление ошибок, которые мы можем сделать, следуя данному рецепту. Эта сторона очень часто скрыта от нас, часто бывает неявным, неформальным дополнением к используемому рецепту.

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

Легко заметить, знание о возможных ошибках может быть переформулировано в шаблон. Так, например, мы исключим переполнение буфера, если в описание шаблона будет будет включена обязательная проверка размера буфера. Для языков типа С, С++, Fortran и подобных эту проверку должен делать программист явно; для языков типа Java или C# такую проверку будет делать среда исполнения.

Вернемся к проверке соответствия. Она может выполняться по-разному, но, вообще, можно выделить три этапа (по моему опыту, на практике очень редко реализуют все эти три этапа).

Первый этап — проверка самим разработчиком. Практически любой программист в большей или меньшей степени проверяет свою работу. Однако, очень редко формальное описание процесса явно требует выполнять это действие; я знаю только TSP и, практически являющийся его частью, PSP (см. [Humphrey2006], [Humphrey2007]), которые делают это.

Второй этап — peer review. Я не стал переводить этот термин, поскольку его знает сейчас практически каждый разработчик. Peer review предполагает проверку работы таким же специалистом, как и тот, что делал основную работу (подробности можно найти в книге [Wiegers2010]). На этом этапе «отлавливается» гораздо больше проблем, чем на первом, поскольку проверку делает человек со свежим взглядом. Другой большой плюс peer review — возможность неявного обучения неопытного специалиста, передача ему опыта от эксперта.

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

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

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

Завершение этапа

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

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

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

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

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

Какой уровень уверенности достаточен? Конечно, это очень сильно зависит от разрабатываемого нами продукта, его критичности; и этот уровень надежности должен быть определен заранее, на этапе формулировки целей.

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

Технический долг

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

Постепенно аналогия стала популярна и в среде специалистов. Так Филипп Крачтен считает, что понятие «технического долга» давно переросло простую аналогию и уже в качестве точного технического термина активно используется при планировании реальной разработки (см., например [Kruchten2012]). Более того, он считает, что это понятие желательно включить в программу обучения студентов, специализирующихся на разработке программного обеспечения ([Falessii2015]).

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

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

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

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

С другой стороны, заемные деньги действительно решают множество проблем. Так мы знаем, иногда взять ипотечный кредит оказывается выгоднее, чем платить за съемную квартиру; компании, которые берут взаймы оборотные средства во многих случаях (в большинстве?) развиваются быстрее, чем те, которые используют только свои.

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

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

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

Конечно, я затронул концепцию технического долга очень поверхностно. Заинтересованного читателя отошлю к литературе. Начать можно с упомянутых здесь двух статей Крачтена; также очень рекомендую почитать соответствующие страницы в блогах других двух известных специалистов: Steve McConnell о техническом долге и Martin Fowler о техническом долге.

Есть возможность и более глубоко познакомится с обсуждаемой концепцией. Читателям, которым необходимо принимать решение, в частности, об использовании «хакинга», и возвращении возникшего долга, очень рекомендую прочитать книгу «Managing Software Debt: Building for Inevitable Change» ([Sterling2010]). Кстати , пятая глава этой книги напрямую описывает подход, который я называю «хакингом», как одну из причин возникновения и роста технического долга; впрочем, компании, увлекающиеся использованием «хакинга», часто создают неподъемный технический долг и другими способами, описанными в этой книге.

Читайте, думайте, применяйте.

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

Изучение системы

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

Этап сбора информации очень хорошо описал Сем Канер (Cem Kaner). Заинтересовавшимся читателям я предложу почитать его работу «A Tutorial in Exploratory Testing» ([Kaner2008]), кстати, термин «exploratory testing» был предложен именно Семом Канером. Конечно, Канер в этой работе говорит не о тестировании безопасности, а о тестировании программного обеспечения вообще, но все его идеи из этой работы полностью применимы и при поиске уязвимостей.

Чтобы не быть слишком абстрактным, давайте немного конкретизируем наш пример. Предположим, на этапе изучения мы обнаружили, что программа написана на C++. Будем в дальнейшем опираться на это наблюдение.

Выдвижение гипотез

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

Здесь мы можем использовать разные информационные источники.

Так многим нравится использовать «шаблоны атак». Большой справочник по известным шаблонам собран на сайте Common Attack Pattern Enumeration and Classification. На этом сайте представлена информация о способах атаки на уязвимости, возникающие в различных частях информационных систем. Подробнее об использовании «Шаблонов атак» вы можете прочитать в книге «Exploiting Software: How to Break Code» ([Hoglund2004]). Похожие идеи вы можете найти и в книге «How to Break Software Security» ([Whittaker2003]).

Некоторые специалисты больше любят говорить о «слабостях системы». Этот подход является дополнительным к «шаблонам атак»: каждая атака использует одну или несколько слабостей наших разработок. Справочник по слабостям различных программ и технологий представлен на сайте Common Weakness Enumeration.

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

Итак, на втором этапе мы сформировали одну гипотезу: изучаемая программа содержит уязвимости «переполнение буфера».

Проверка гипотез

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

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

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

Вернемся к нашему примеру.

Для проверки возможности переполнения буфера мы можем использовать «fuzzing». При использовании этой техники на вход программы подается большое количество случайных данных, и наблюдаются реакции программы на это воздействие. По практике, техника «fuzzing» эффективна для обнаружения ошибок, связанных с переполнением буфера (см., например, [Howard2009]); если в тестируемом приложении есть ошибки, связанные с отсутствием контроля входных данных, очень вероятно, что приложение «упадет». Преимуществом метода является ее простота и высокая автоматизируемость — закодировать такой тест может более или менее разбирающийся студент, а дальше проверка программы происходит вообще без участия человека. Недостаток метода — большое время работы и негарантированность результата.

Предположим, наша гипотеза подтвердилась — приложение позволяет осуществить переполнение буфера и, возможно, оно уязвимо.

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

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

Поэтому в нашем примере мы закончим этап на обнаружении возможности переполнения буфера.

Обобщение

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

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

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

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

Окончание цикла проверки

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

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

Стратегии

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

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

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

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

Навыки

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

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

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

Сравнение

Теперь мы можем сопоставить информацию из полученных таблиц.

Хорошо видно разделение ролей на две группы.

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

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

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

Можно заметить и еще одну особенность: «творческие» роли немного пересекаются. Действительно, как мы видели, разработчик-изобретатель должен уметь делать индуктивные выводы, анализируя тенденции развития средств защиты и стараясь их продолжить; то есть, он должен проявлять кроме инженерных еще и аналитические способности. В свою очередь хакер-исследователь должен уметь проектировать «эксплойты», и прогнозировать поведение атакуемого объекта.

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

Но здесь есть несколько тонких различий.

Известнейший пример двойственности восприятия. Что вы видите: вазу или два лица? Рисунок взят из Википедии

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

Эксперт отличается от новичка именно простроенным пространством задачи (см., например, [Anderson2002]). Как только задача уходит из этого пространства, его преимущества перед новичком сразу полностью теряются. Так, например, известно, что шахматист легко запоминает позицию на доске, но произвольный набор фигур запоминает ничем не лучше, чем обычный человек, поскольку задача не вписывается в известные ему шаблоны.

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

Другими словами: пересечение есть, но оно очень и очень слабое.

Между «инженерными» ролями вообще нет никаких пересечений.

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

Интеллект организации

Не только человек может считаться интеллектуальным агентом.

Очень интересна аналогия группы и отдельного человека. Оказывается, внедрение новой технологии, новой методики работы, нового процесса очень удобно рассматривать, как обучение группы, организации. Здесь можно проследить все те же самые этапы, столкнуться с аналогичными трудностями. Более того, у организации даже можно выделить некоторую аналогию нашего сознания и подсознания (см., например, [Polanyi1958]).

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

Организация собирает, хранит и обрабатывает информацию. Исследование этой стороны деятельности организации в последние десятилетия привлекают все больше и больше внимания (см., например, [Patriotta2003]). Очевидно, результаты этих исследований позволяют более эффективно строить деятельность компаний.

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

Что мы знаем

Декларативные знания я бы по-другому назвал теоретическими. К этой категории относится следующая информация ([Foshay2003]):

• факты (2×2=4);
• концепции, категории предметов (чем табуретки отличаются от стульев);
• правила (если замерзнешь, то можно заболеть);
• ментальные модели, объединяющие все эти знания в единый комплекс.

Я здесь же упомянул бы и знание последовательности выполнения действий.

В западной традиции обучение начинают с декларативных знаний (см., например, [Anderson2002], [Foshay2003]). Ученикам, слушателям сначала передается информация — декларативные знания, — необходимые им для решения задачи, а уже потом они приобретают опыт ее решения, у них формируются процедурные навыки.

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

Что мы умеем

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

Большинство наших действий мы выполняем неосознанно. Так, мы практически никогда не задумываемся, как мы ходим; мы не задумываемся над последовательностью действий, когда нам надо вскипятить воду для заварки чая. Забегая вперед, именно так мы решаем задачи хорошо известного нам типа: не задумываясь о последовательности решения, автоматически выполняя все необходимые мыслительные операции.

Наше поведение при реализации таких действий хорошо описываются моделью ТOTE. Эта модель поведения была предложена еще в 60-е годы прошлого столетия и описана в ставшей сейчас классикой книге «Plans and the Structure of Behavior» ([Miller1960]). Сейчас разработаны более подробные и более точные модели, но TOTE хороша своей простотой и наглядностью, именно за это ее любят практики. Читателей, заинтересовавшихся этой темой, отошлю к отличному сборнику статей «The Cognitive Psychology of Planning» ([Moris2005]), в особенности к вводной его статье ([Ward2005]).

Модель TOTE описывает практически рефлекторную последовательность:

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

Все что мы делаем хорошо — мы делаем автоматически. Именно на достижение автоматизма операций направлены тренировки и тренинги. Экспертные умения автоматичны и неплохо описываются уже упомянутой моделью TOTE; поэтому моделировать знания/умения эксперта также можно в форме описания последовательно проверок-действий (см., например, [Dilts1998]).

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

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

Хорошо определенная задача

В хорошо определенной задаче все элементы известны.

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

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

Стратегии решения хорошо определенной задачи удобно изучать на примере планирования маршрута.

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

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

Существует несколько общих стратегий решения этой задачи.

Заинтересовавшихся отошлю к специальной литературе. Кроме уже неоднократно упоминавшихся здесь книг по когнитивной психологии и искусственному интеллекту, могу порекомендовать статью «Planning and problem solving in well-defined domains» ([Davies2005]).

Здесь же мы только обсудим общий подход к решению.

Нечетко поставленная задача

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

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

Конечно, нам кое-что уже понятно. Заинтересовавшихся читателей отошлю к специальной литературе, в частности к хорошей статье «Planning and ill-defined problems» ([Ormerod2005]). Мы же здесь обсудим только один аспект проблемы — две различные стратегии решения таких задач.

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

Анализ и синтез

Анализ и синтез — взаимно обратные операции.

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

В ходе синтеза мы «собираем» объект из частей. Мы комбинируем отдельные части с известными нам свойствами, организуем их взаимодействие; таким образом мы создаем новый объект, возможно, обладающий новыми качествами. Подобно анализу, синтез может быть как реальным, так и мысленным.

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

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

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

Дедукция и индукция

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

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

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

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

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

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

Еще раз. При дедуктивном рассуждении мы работаем с достоверными фактами, мы имеет достоверные факты на входе — мы имеем достоверные факты на выходе.

Теперь перейдем к индукции.

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

Пример задачи на индукцию из теста на IQ. Вам предлагается продолжить следующий ряд чисел: 2,4,6… (ну это очень простой тест, для школьников). Мы можем предположить, что эти числа — начала ряда, состоящего из четных чисел; тогда его продолжение будет: …8, 10, 12…

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

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

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

Дедуктивная и индуктивная стратегия очень сильно различаются психологически. Каждая из них формирует свое «ощущение», интуитивное понимание «истины»; и это понятно, ведь дедуктивная «истина» абсолютна, а индуктивная — вероятностна. Конечно, мы так или иначе применяем обе этих стратегии, более того, есть люди, которые легко переключаются между ними и легко используют наиболее подходящую из них. Тем не менее, очень часто люди предпочитают использовать одну из этих стратегий (см., например, [Hall2007]).

Похоже, индукция более естественна для человека.

Дедукция основана на применении абстрактных правил. В отличие от индукции, которая основана на манипуляциях с относительно конкретными «предметами», при дедуктивных операциях мы имеем дело с «категориями».

Необходимость работать с абстрактными понятиями усложняет задачу. Люди хорошо оперируют с чем-то конкретным, и не очень хорошо с обобщениями. Поэтому, например, школьников учат сложению сначала на примере простых предметов — яблок, счетных палочек и подобных, — и только потом рассказывают про правила сложения, вычитания; не прошедшие обучение дети хорошо оперируют количеством предметов, но плохо — абстрактными числами ([Anderson2002], [Solso1996]).

Для взрослого человека абстракции также представляют сложностью. Так при разработке тестовых заданий необходимость оперировать абстрактными понятиями считается усложнением задачи ([Oosterhof2008]).

Частая ошибка в логики — замена дедукции индукцией. Даже достаточно образованные люди решая задачи, где надо применить правило — воспользоваться дедуктивной логикой, — стараются применить индуктивные выводы ([Anderson2002]).

Думаю, именно дедуктивность делает математику такой трудной дисциплиной.