Управление разработкой безопасных систем и Оценка систем: Комплексный анализ

Управление проектами, Риски и Организационная психология

Введение в управление безопасностью

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

Управление проектом безопасности и оценка рисков

Самая сложная задача менеджера проекта по безопасности — понять компромисс между риском и вознаграждением. Специалисты по безопасности естественным образом фокусируются на рисках и часто упускают из виду потенциальную выгоду.
Рассмотрим гипотетическую ситуацию: у компании оборот составляет $10 млн, прибыль — $1 млн, а убытки от краж — $150 000. Консультант по безопасности может предложить меры, которые «сократят убытки и увеличат прибыль на 15%». Однако в интересах акционеров может быть удвоение оборота до $20 млн, даже если это утроит убытки от краж до $450 000. При сохранении прежней маржинальности прибыль вырастет до $1,85 млн (рост на 85%). Поэтому владельцам бизнеса не следует попадать в ловушку мышления, что на любую уязвимость нужно реагировать исключительно ее «лечением». Часто безопасность уже избыточна, и ресурсы нужно перенаправить в другое русло. Но поскольку команды безопасности (внутренние или внешние) имеют стимул преувеличивать угрозы, а их экспертизу сложно оспорить, этот баланс требует жесткого управления.

Кейс: Три супермаркета (A Tale of Three Supermarkets)

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

1. Автоматизация через RFID (Южная Африка). Один супермаркет решил полностью автоматизировать процесс. Все товары должны были иметь RFID-метки, чтобы целая тележка считывалась автоматически. Это убило бы двух зайцев: сократило штат кассиров и усложнило кражи. Однако пилотный проект провалился. Метки плохо считывались с токопроводящих товаров (например, консервных банок), а использование специальных тележек оказалось неудобным и эстетически непривлекательным для покупателей.
2. Распознавание лиц и гражданские иски (Европа). Другая сеть изначально пыталась использовать RFID, чтобы остановить профессиональных воров. Когда это не сработало, они обратились к системам распознавания лиц для оповещения охраны. Эта технология также не обеспечила требуемого уровня точности. В итоге сеть перешла к тактике «гражданского взыскания»: после того как магазинная кража фиксировалась полицией и штрафом, супермаркет подавал на вора в гражданский суд за «потерянное время и моральный ущерб», а затем арестовывал имущество должника. Однако менеджмент настолько увлекся местью мелким воришкам, что потерял фокус на маркетинге и увеличении продаж. В результате сеть потеряла долю рынка, а ее акции упали.
3. Самообслуживание и доверие (Waitrose, Англия). Сеть Waitrose внедрила систему самообслуживания. Покупатель сканирует свою карту лояльности, получает портативный сканер, сканирует товары по мере их сбора и кладет их в сумку. На выходе данные сверяются, и оплата проходит по кредитной карте. Эта система элегантно решает проблему краж: доступ к самообслуживанию имеют только владельцы карт лояльности (что автоматически исключает известных магазинных воров и стимулирует выдачу карт). Покупатель чувствует себя «доверенным лицом». Если охрана на экране замечает подозрительное поведение, система может намеренно «сломаться» на кассе самообслуживания, что дает персоналу повод вежливо попросить покупателя показать содержимое сумки без открытого конфликта.

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

Организационные вопросы и психология безопасности

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

Цикл беспечности и Термостат риска

В индустрии телефонного мошенничества в США существует семилетний цикл: одна из региональных компаний (Baby Bells) несет убытки, нанимает экспертов, выстраивает защиту, после чего цикл повторяется у следующего игрока. Это классический пример организационной беспечности.
Джон Адамс в своем исследовании законов об обязательных ремнях безопасности обнаружил, что они не спасают жизни, а лишь перераспределяют жертвы: количество погибших водителей сокращается, но растет число погибших пешеходов и велосипедистов. Почему? Ремни безопасности заставляют водителей чувствовать себя защищенными, и они начинают ездить быстрее, чтобы вернуть свое субъективное восприятие риска на прежний уровень. Адамс назвал это «термостатом риска».
Механизмы обратной связи ограничивают эффективность систем снижения рисков. Как только уровень инцидентов падает до минимума, бдительность притупляется: охранники засыпают, реальные угрозы тонут в ложных срабатываниях, а бюджеты на безопасность урезаются до опасного предела.

Взаимодействие с надежностью (Reliability)

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

Решение неправильной проблемы

Сталкиваясь со сложной проблемой, организации часто начинают яростно атаковать смежную, но более легкую задачу (деятельность по смещению фокуса).
Отличный пример — индустрия смарт-карт. Столкнувшись со сложностью защиты чипов от зондирования и анализа электропитания (power-analysis), производители решили защищать, секретность фотошаблонов (chip masks). В результате появились технические руководства, доступные только по NDA, посетители на заводы должны подписывать соглашения о неразглашении, а отходы уничтожаются в шредерах. Эта физическая паранойя впечатляет наивных клиентов, но почти все реальные атаки на смарт-карты используют технические уязвимости, для которых знание топологии чипа не требуется.

Некомпетентные менеджеры и Моральный риск

В традиционных компаниях продвижение на высшие должности часто зависит от стажа и связей. Быть менеджером по безопасности — значит постоянно говорить «нет», что делает эту должность нежелательной для карьеристов. В результате средний срок пребывания в должности менеджера по кибербезопасности в госучреждениях США составляет всего 7 месяцев. Частые реорганизации уничтожают институциональную память, а функция безопасности сводится к «отметке галочек» для соблюдения формальных требований.
Другая серьезная проблема — моральный риск, возникающий, когда системы проектируются так, чтобы переложить риск на третьи стороны. Это лишает компанию стимулов инвестировать в реальную защиту. Например, если банки заявляют, что их банкоматы непогрешимы, а ответственность за «фантомные снятия» лежит на клиенте, персонал банка расслабляется и перестает расследовать инциденты. В таких условиях сотрудники становятся ленивыми, а иногда и сговорчивыми с мошенниками, зная, что банк все равно спишет убытки на жертву.
Моральный риск также возникает, когда лица, принимающие решения, не несут ответственности за последствия. Высокая текучка ИТ-кадров, reliance на подрядчиков или амбициозные менеджеры, которые не хотят спорить с разработчиками ради краткосрочного релиза, — все это ведет к тому, что через три года, когда система взломают, виновных уже не найти.

Методологии, Инженерия требований, Управление рисками и Командой

Методология разработки

Программные проекты обычно занимают больше времени, стоят дороже и содержат больше ошибок, чем ожидалось. К 1960-м годам это явление стало известно как «кризис программного обеспечения». В ответ на него Брайан Рэндалл в 1968 году предложил термин «инженерия программного обеспечения», выразив надежду, что проблему можно решить так же, как строят корабли и самолеты — с использованием проверенной научной базы и набора правил проектирования.
На практике инструменты инженерии программного обеспечения помогают разработчикам забираться все выше на гору сложности, прежде чем они сорвутся вниз, но частота катастрофических сбоев крупных проектов остается неизменной. Управлять сложностью помогают два основных подхода: нисходящий (top-down) и итеративный.

Нисходящее проектирование (Модель водопада)
Классической моделью является «водопад», разработанный Уином Ройсом в 1960-х годах для ВВС США. Идея заключается в последовательном прохождении этапов: от краткого изложения требований к спецификации, затем к реализации и модульному тестированию, интеграции и системному тестированию, и, наконец, к развертыванию.
Сильные стороны водопада заключаются в том, что он заставляет рано прояснять цели системы, архитектуру и интерфейсы, облегчает задачу менеджера проекта, предоставляя четкие вехи и совместим с широким спектром инструментов. Однако его главный недостаток — отсутствие системной обратной связи от тестирования к требованиям. Если требования не известны заранее в деталях, эта модель неприменима.

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

1. Спиральная модель Барри Бёма предполагает создание прототипа и его тестирование на каждом этапе, позволяя менеджерам оценивать риски и решать, продолжать ли работу или свернуть проект.
2. Эволюционная разработка, популяризированная Харланом Миллсом, предполагает создание минимальной работающей системы, ее тестирование реальными пользователями и постепенное добавление функциональности. Именно так работает индустрия packaged software: продукты становятся настолько сложными, что их невозможно переписать с нуля.

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

Уроки критически важных систем (Safety-Critical Systems)

Методологии разработки критически важных систем (например, систем управления полетом или автоматического торможения) предлагают ценные уроки для инженеров безопасности. Обычно они следуют «водопадной» парадигме: выявление опасностей и оценка рисков, выбор стратегии (избегание, ограничение, избыточность), трассировка опасностей до аппаратных и программных компонентов, анализ процедур оператора и, наконец, создание плана тестирования и Safety Case (доказательства безопасности).

Устранение опасностей (Hazard Elimination)
Идеальное проектирование полностью избегает опасностей. Классический пример — схемы реверсирования двигателя. В исходной конструкции использовался переключатель с двумя полюсами: если перемещался только один полюс, батарея замыкалась накоротко, что могло вызвать пожар. Решение состояло в том, чтобы поменять местами батарею и двигатель. В модифицированной схеме отказ переключателя просто замкнет двигатель, а не батарею. В безопасности это аналогично минимизации доверенной вычислительной базы (TCB).

Анализ деревьев отказов и угроз (Fault Tree / Threat Tree Analysis)
Для выявления потенциальных сбоев используется анализ деревьев отказов (сверху вниз) или анализ видов и последствий отказов — FMEA (снизу вверх, пионером которого была NASA). В инженерии безопасности это трансформируется в анализ деревьев угроз. Например, для банкомата корень дерева — «Успешная подделка карты». Ветви включают: снятие данных через плечо (shoulder surfing), криптоанализ DES, атаку через ложный терминал, злоупотребление модулем безопасности, троян, кражу ключей, инсайдера или подрядчика по обслуживанию, ошибку в протоколе и т.д. Обход листьев дерева дает руководство по атаке на систему, которое должно существовать у оценщиков: если они найдят значительные дополнительные атаки, продукт не пройдет сертификацию.

Человеческий фактор
Библией для инженерии человеческого фактора является книга Джеймса Ризона «Human Error». Частота ошибок зависит от знакомства и сложности задачи, давления и наличия подсказок. Если задача проста и выполняется часто, частота ошибок может составлять 1 на 100 000. Но если задача выполняется впервые в запутанной среде под давлением, вероятность успеха резко падает. Инженер по безопасности должен понимать когнитивные искажения и избегать их. Как и в случае с пилотами, которых тренируют в симуляторах, комбинируя отказы оборудования и плохую погоду, безопасность должна быть встроена в систему с самого начала, а не добавлена постфактум.

Маскировка неисправностей (Fault Masking)
В системах с резервированием возникает проблема маскировки: если три процессора голосуют большинством, и один из них дает сбой, система продолжит работать, но ее запас прочности будет подорван. В безопасности примером служит случай, когда банк по ошибке выдал всем своим клиентам одинаковый PIN. Ошибка была замаскирована процедурами обработки PIN-кодов, которые гарантировали, что даже сотрудники службы безопасности получали только свой личный PIN-конверт. Проблема обнаруживалась только спустя долгое время.

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

Инженерия требований безопасности и управление их эволюцией

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

1. Исправление багов (Bug Fixing)
Если вы продаете критически важный софт, столкновение с уязвимостью неизбежно. План реагирования должен состоять из четырех компонентов:

• Мониторинг: Необходимо узнавать об уязвимостях как можно быстрее. Полезно иметь систему вознаграждений для клиентов или исследователей за найденные баги.
• Ремонт: В организациях с критическими требованиями кто-то из команды должен быть «на дежурстве» с пейджером. Экстренные исправления должны проходить полный цикл тестирования, а документация (и модель угроз) должна обновляться.
• Распространение: Патч должен быстро доходить до клиентов. Существует серьезное напряжение между желанием быстро пропатчить систему и необходимостью тщательно протестировать исправление. Это привело Microsoft к введению «Patch Tuesday» (второй вторник каждого месяца), что стало разумным компромиссом между безопасностью, надежностью и управляемостью.
• Успокоение (Reassurance): Необходимо заранее подготовить шаблоны пресс-релизов для инцидентов разной степени тяжести, чтобы журналисты не получали отпор от операторов колл-центра, пока вы лихорадочно чините баг.

2. Настройка контроля и корпоративное управление
Основной процесс развития внутренних контролей (например, в банках) — это их настройка на основе опыта. Инженеру по безопасности важно понимать стандарты внутреннего аудита. Наиболее влиятельным является COSO (Committee of Sponsoring Organizations) — структура управления рисками, которая задает тон для компаний, котирующихся на биржах США. Другой важный стандарт — CobiT, который более адаптирован к ИТ-потребностям и охватывает управление персоналом, контроль изменений и управление проектами.
Дополнительными драйверами выступают законы, такие как Sarbanes-Oxley (требует документирования мер безопасности), Gramm-Leach-Bliley (для финансового сектора США) и HIPAA (для здравоохранения). В Европе давление оказывает законодательство о защите персональных данных и законы об обязательном уведомлении о нарушениях безопасности (breach disclosure laws).

3. Эволюционирующие среды и Трагедия общин
Многие системы ломались после изменения окружающей среды, когда адекватные изменения в механизмах защиты были проигнорированы или забыты. Например, технология карт и PIN-кодов, отлично работавшая с банкоматами, стала уязвимой к атакам через ложные терминалы в розничных точках.
Проблема усугубляется, когда никто полностью не владеет системой. Ответственность за стандарты проверки PIN-кодов банкоматов размыта: IBM, разработавшая большинство стандартов, утратила лидирующую роль, Microsoft не заинтересована в рынке банкоматов, VISA прекратила сертификацию оборудования около 1990 года, а Mastercard никогда этим не занималась, консорциум EMV появился позже. В таких условиях каждый игрок (производитель оборудования или банк) имеет мотивацию немного раздвинуть границы, надеясь, что если что-то пойдет не так, это случится с кем-то другим. В экономике это называется трагедией общин: если сотне крестьян разрешено пасти овец на общем пастбище, каждый добавит еще одну овцу, получив почти полную выгоду, в то время как остальные 99 понесут лишь небольшой ущерб от ухудшения качества травы. Результат — пыльная пустошь.

4. Организационные изменения
Организационные вопросы часто являются первопричиной сбоев. В начале 1990-х годов модным течением было реинжиниринг бизнес-процессов, который часто означал использование изменений в компьютерных системах для принуждения людей к изменению способов работы.
Классический пример катастрофы — Лондонская служба скорой помощи. Менеджеры решили автоматизировать систему, чтобы сократить расходы и решить проблемы с трудовыми отношениями. Когда систему начали внедрять, выяснилось, что она не справляется с устоявшимися практиками (например, экипажи брали «не те» машины, так как у старших сотрудников были лучшие). Менеджеры проигнорировали это и 26 октября 1992 года принудительно перевели диспетчеров на терминалы. Результатом стал коллапс. Возникли петли положительной обратной связи: система теряла контроль над машинами, исключения накапливались и пропадали с экранов, время отклика росло, экипажи расстраивались и нажимали не те кнопки на терминалах, что увеличивало заторы. В итоге служба парализовалась, и, по оценкам, около двадцати человек погибли из-за несвоевременного оказания помощи. К концу дня система была переключена обратно на полуручной режим.

Управление требованиями проекта

Если система создается с нуля (например, новое приложение для электронной коммерции), процесс требует итеративного подхода, скорее спиральной модели, чем водопада.
Влиятельной публикацией в этой области является книга Фрэнка Свидерски и Уиндоу Снайдер по моделированию угроз (Threat Modelling), описывающая методологию Microsoft. Идея заключается в перечислении защищаемых активов и активов, доступных атакующему, с последующей трассировкой через систему для определения уровней доверия, путей атаки, барьеров и техник (спуфинг, фальсификация, отказ от авторства, раскрытие информации, отказ в обслуживании, повышение привилегий). Модель угроз используется для обзоров архитектуры, целевых проверок кода и тестов на проникновение.

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

Управление рисками

В основе любых требований безопасности лежат бизнес-решения о приоритетах: сколько тратить на защиту от чего. Это управление рисками, которое должно вписываться в более широкие рамки управления не-ИТ рисками.
Самая распространенная техника — расчет ALE (Annualized Loss Expectancy) — ожидаемых годовых убытков. Это ожидаемый убыток, умноженный на количество инцидентов, ожидаемых в среднем за год. Типичный анализ ALE для компьютерных систем банка может включать сотни записей:

• Мошенничество SWIFT: Убыток $50,000,000, Вероятность 0.005 -> ALE $250,000
• Мошенничество с банкоматом (крупное): Убыток $250,000, Вероятность 0.2 -> ALE $100,000
• Кража наличных кассиром: Убыток $3,240, Вероятность 200 -> ALE $648,000

Точные цифры доступны для частых потерь, тогда как для редких, но высокорисковых событий вероятность — это во многом догадка. На практике процесс составления такой таблицы часто превращается в итеративные догадки: консультант перечисляет угрозы, прикрепляет номинальные вероятности, получает абсурдный результат (например, ALE банка превышает его доход), а затем «подгоняет» вероятности, чтобы получить цифру, оправдывающую максимальный бюджет безопасности, который, по его мнению, согласится одобрить совет директоров. ALE могут быть полезны, но их не следует возводить в религию.
Страхование может помочь в управлении крупными, но маловероятными рисками. Однако для компаний, котирующихся на бирже, важной причиной покупки страховки от компьютерных преступностей является due diligence (должная осмотрительность). Риски, которые кажутся операционными, на самом деле часто являются юридическими и регуляторными.

Управление командой

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

Баланс ответственности и специализации
Одна из самых сложных задач — найти баланс между тем, чтобы каждый разработчик отвечал за безопасность своего кода, и наличием гуру по безопасности, на которого все полагаются.
Важный урок дал опыт Microsoft в борьбе с IBM на рынке операционных систем. В конце 1980-х они сотрудничали над OS/2, но партнерство распалось в 1990 году. IBM следовала модели водопада, разделяя разработчиков на аналитиков, программистов и тестировщиков. Это создавало моральный риск: программисты писали много некачественного кода и «перебрасывали его через стену» тестировщикам. В результате кодовая база часто была настолько сломана, что не компилировалась, и регрессионные тесты было невозможно запустить.
Microsoft заняла позицию, что у них нет программистов или тестировщиков, а есть только разработчики: каждый программист обязан исправлять свои баги («if you wrote it, you fix it»). Большое внимание уделялось тому, чтобы программное обеспечение собиралось каждую ночь для тестирования. В итоге люди, писавшие баговый код, тратили большую часть времени на охоту и исправление собственных ошибок, поэтому большая часть кодовой базы писалась более аккуратными программистами. Это позволило Microsoft захватить рынок 32-битных ОС.

Capability Maturity Model (CMM)
Для управления качеством используется модель зрелости возможностей (CMM) от Института программной инженерии при Университете Карнеги-Меллона. Исследования показали, что компетентность — это функция команд, а не только отдельных разработчиков. Недавно сформированные команды склонны недооценивать объем работы и имеют высокую дисперсию времени выполнения. Команды, которые работают слаженно, не только лучше предсказывают сроки, но и снижают дисперсию.
CMM предлагает процесс сертификации, при котором устоявшиеся команды могут получить статус актива, которым нельзя легкомысленно разбрасываться при реорганизациях. Модель имеет пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий.

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

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

Концепция Assurance (Гарантии), Экономические стимулы и Рост надежности

Введение в Assurance (Гарантии)

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

Извращенные экономические стимулы

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

Стимулы критически важны. Если люди на самом деле не хотят защищать систему, заставить их это сделать крайне сложно. Они находятся за рамками формального процесса Assurance, но являются самой важной частью среды, в которой должна определяться политика безопасности.
Политики часто игнорируются: люди в итоге защищают не то, что нужно, или защищают нужные вещи неправильным способом.
Механизмы регулярно попадают в новости. Например, экспортный контроль привел к тому, что DVD выпускались с 40-битными ключами, которые были уязвимы по своей сути. Трудность защиты смарт-карт от зондирования и атак по электропитанию привела к тому, что индустрия сосредоточилась на защите других, относительно неважных вещей, таких как секретность фотошаблонов (chip masks).
Гарантии традиционно фокусировались на реализации (поиск и исправление переполнений стека). В последние годы, с переходом от «Оранжевой книги» к Common Criteria, политика также вошла в общие рамки Assurance через механизмы профилей защиты (protection profiles).

Однако самый большой упущенный фактор в традиционном подходе к оценке — это юзабилити (usability). Большинство сбоев на уровне системы (в отличие от чисто технических) имеют значительный человеческий компонент. Дизайнеры часто рассматривают гарантии просто как отсутствие очевидных багов, связывая технические механизмы защиты, но не учитывая человеческую слабость. (Есть почетные исключения: системы бухгалтерского учета с самого начала проектируются так, чтобы справляться как с ошибками, так и с умыслом, а технологии защитной печати оптимизируются для того, чтобы облегчить обычным людям поиск подделок). Юзабилити касается не только конечных пользователей, но и разработчиков. Элементы управления доступом в стандартных ОС часто не используются, потому что программистам гораздо проще заставить код работать с правами администратора.
Вышеуказанные факторы взаимозависимы и во многих случаях вступают в конфликт со стимулами. Клиенты и поставщики часто хотят разного.
Рациональный пользователь ПК, например, хочет: высокое юзабилити, средние гарантии (высокие были бы дорогими, а с редким вирусом можно смириться), высокую стойкость механизмов (они не стоят намного дороже) и простую функциональность (юзабилити важнее). Но рынок не предоставляет этого.
Коммерческие поставщики платформ выбирают богатую функциональность (каждая функция приносит выгоду более концентрированной группе пользователей, чем ее стоимость, быстрая смена версий предотвращает коммодитизацию рынка, а сторонние разработчики, захватывающие слишком большую долю рынка, могут быть подавлены), низкую стойкость механизмов (за исключением криптографии, где эскроу-дебаты заставили их рассматривать стойкую криптографию как важнейшую маркетинговую фишку), низкие гарантии реализации (военная криптография легко обходится «троянскими конями») и низкое юзабилити (программисты-разработчики приложений гораздо важнее для сетевых эффектов, чем клиенты).
Ранее об экономике мы описывали, почему это не изменится в ближайшее время. Компании, борющиеся за доминирование на рынках платформ, начинают с поставки слишком малого объема безопасности, так как она мешает сторонним разработчикам (complementers), к которым они должны апеллировать, а та безопасность, которую они все же поставляют, часто бывает «неправильной», поскольку предназначена для перекладывания затрат на пользователей, даже если эти затраты лучше несли бы сторонние разработчики. Как только фирма достигает доминирования на рынке платформ, она добавляет безопасность, но опять же «неправильную», поскольку ее стимулом теперь является максимальная привязка (lock-in) своих клиентов. Мы видели это не только на платформе ПК, но и на мейнфреймах, мобильных телефонах и даже на телефонных коммутаторах. Таким образом, поставщики обеспечивают меньше безопасности, чем хотел бы рациональный клиент и, в свою очередь, клиент хочет меньше, чем было бы социально оптимально, поскольку многие затраты на подключение небезопасной машины к Интернету ложатся на других.
Идеалы государственных агентств также разбиваются о экономику. Они хотели бы иметь возможность покупать готовые коммерческие продукты (COTS), заменять небольшое количество компонентов (например, подключая криптографические карты вместо стандартной криптографии для секретных версий) и просто использовать результат в оборонных сетях. Поэтому они хотят многоуровневую функциональность и высокие гарантии реализации. Этот список пожеланий нереалистичен не только из-за стоимости высоких гарантий, но и из-за приоритета времени выхода на рынок, необходимости угождать сообществу разработчиков и потребности в частой смене версий продуктов, чтобы предотвратить коммодитизацию рынков. Кроме того, миллион государственных компьютерных пользователей не могут ожидать, что навяжут свою волю 500 миллионам пользователей Windows и Office.
Именно в этом коварном ландшафте с его множеством неразрешимых политических конфликтов и разыгрывается игра в Assurance.

Проектные гарантии (Project Assurance)

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

Тестирование безопасности

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

1. Сначала ищутся архитектурные flaws (недостатки). Использует ли система угадываемые или слишком постоянные идентификаторы сессий? Есть ли способ внедрить код, например, протащив SQL через веб-сервер в базу данных бэкенда? Согласована ли политика безопасности, или в предположениях есть пробелы? Приводят ли они к пробелам между механизмами, где можно делать злонамеренные вещи?
2. Затем ищутся недостатки реализации, такие как переполнение стека и целочисленное переполнение. Обычно это включает не только просмотр кода, но и использование специализированных инструментов, таких как фаззеры (fuzzers).
3. Затем прорабатывается список менее распространенных недостатков. Если продукт использует криптографию, ищут слабые ключи (или ключи, установленные в постоянные значения) и плохие генераторы случайных чисел, если есть компоненты с различными предположениями о доверии, пытаются манипулировать API между ними, ища условия гонки (race conditions) и другие комбинации транзакций, которые имеют зловредные эффекты.

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

Формальные методы

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

Quis Custodiet? (Кто будет следить за надзирателями?)

Точно так же, как ошибки могут быть допущены доказывающими теоремы и тестировщиками, они также могут быть допущены людьми, которые составляют чек-листы вещей для тестирования (и авторами учебников по безопасности, из чьих трудов составители чек-листов черпают идеи). Это старая проблема quis custodiet ipsos custodes, как более лаконично выразились римляне.
Есть несколько вещей, которые можно сделать, и немногие из них, вероятно, понравятся организации, чья цель — получить декларацию о том, что продукт не имеет недостатков. Очевидный вариант — внедрение ошибок (fault injection), при котором в код намеренно вводится ряд ошибок случайным образом. Если есть сто таких ошибок, и тестировщик находит семьдесят из них плюс еще семьдесят, которые не были введены намеренно, то после удаления тридцати оставшихся преднамеренных ошибок можно ожидать, что осталось около тридцати неизвестных вам багов. (Это предполагает, что неизвестные вам ошибки распределены так же, как и известные, в реальности все почти всегда будет хуже).
Даже в отсутствие намеренного внедрения багов, грубую оценку можно получить, посмотрев, какие баги находят какие тестировщики.
Таким образом, мы получаем обратную связь из скорости, с которой экземпляры известных багов обнаруживаются в продуктах после их выпуска. Другим фактором является скорость, с которой обнаруживаются новые атаки. В университетской системе мы обучаем аспирантов, позволяя им атаковать разные вещи, новые уязвимости и эксплойты попадают в исследовательские работы, которые приносят известность и в конечном итоге продвижение по службе. Стимулы в правительственных агентствах и корпоративных лабораториях немного отличаются, но общий эффект тот же: большая группа способных мотивированных людей ищет новые эксплойты.

Процессные гарантии (Process Assurance)

В последние годы все меньше внимания уделяется мерам Assurance, сосредоточенным на продукте, таким как тестирование, и все больше — процессным мерам, таким как то, кто разработал систему. Как знает любой, кто занимался разработкой систем, некоторые программисты пишут код с количеством багов на порядок меньше, чем другие. Существуют также организации, которые производят код гораздо более высокого качества, чем другие. Это предмет пристального внимания в индустрии.
Как отмечалось ранее, некоторые различия между разработчиками высокого и низкого качества поддаются прямому управленческому вмешательству. Действительно важным фактором является то, несут ли люди ответственность за исправление собственного кода. В 1980-х годах многие организации интерпретировали водопадную модель разработки систем так, что одна команда писала спецификацию, другая писала код, третья занималась тестированием (включая исправление некоторых багов), а четвертая занималась обслуживанием (включая исправление остальных багов). Они общались друг с другом только через проектную документацию. Это оправдывалось тем, что людям эффективнее концентрироваться на одной задаче за раз, поэтому прерывание работы программиста с просьбой исправить баг в коде, который он написал шесть месяцев назад и о котором забыл, может стоить дня продуктивности, в то время как привлечение программиста службы поддержки для этого может стоить всего час.
Но эффект заключался в том, что кодеры производили мегабайты некачественного кода и оставляли бедным тестировщикам возможность разгребать завалы. Со временем и качество, и продуктивность просели. Промышленные аналитики приписывали опыт IBM, балансирующей на грани смерти в начале 1990-х годов (что стоило более 100 миллиардов долларов стоимости активов), именно этому.
Со своей стороны, Microsoft считает, что одним из самых важных уроков, извлеченных ею в борьбе с проблемами написания все более крупных программ, было внедрение твердой политики «если ты это написал, ты это и исправляешь» (if you wrote it, you fix it). Баги должны исправляться как можно скорее и даже несмотря на то, что они так же неизбежны, как смерть и налоги, программисты никогда не должны сдаваться, пытаясь писать чистый код. Одним из последствий стало то, что люди, которые писали баговый софт, в итоге тратили большую часть своего времени на поиск и исправление багов в своем коде, поэтому большая часть кодовой базы в итоге писалась более аккуратными программистами.
Другие контролируемые аспекты организации также могут иметь значительное влияние на качество выпускаемой продукции, начиная от того, насколько яркими являются ваши наймы, и заканчивая тем, как вы их обучаете и какие рабочие привычки прививаете.
В течение некоторого времени внутренние аудиторы включали процессные вопросы в оценку качества кода безопасности. Это сложнее сделать, чем может показаться, потому что большая часть культуры качества организации нематериальна. Хотя некоторые правила (такие как «исправляй свои собственные баги») кажутся довольно универсальными, навязывание большого количества конкретных правил вызвало бы бюрократическую культуру «простановки галочек», а не динамичную конкурентную среду. Поэтому недавняя работа стремилась к более целостной оценке возможностей команды, главным претендентом здесь является Capability Maturity Model (CMM) от Института программной инженерии при Университете Карнеги-Меллона.
CMM основан на идее, что компетентность — это функция команд, а не просто отдельных разработчиков. В группе есть нечто большее, чем просто сбор полудюжины компетентных музыкантов, и то же самое касается программного обеспечения. Разработчики начинают с разными стилями кодирования, разными соглашениями для комментирования и форматирования кода, разными способами управления API и даже разными ритмами рабочего процесса. Как описывалось ранее, способный руководитель проекта объединит их в команду, обеспечив согласие в отношении соглашений и способов работы, развивая понимание сильных сторон разных людей и лучше сопоставляя их с задачами. Исследования Карнеги-Меллона показали, что недавно сформированные команды, как правило, недооценивают объем работы в проекте, а также имеют высокую дисперсию времени, которое им требуется, команды, которые лучше всего работали вместе, были гораздо лучше способны предсказать, сколько времени им потребуется, с точки зрения среднего времени разработки, но также снижали и дисперсию.
Теперь одна из проблем заключается в том, что фирмы постоянно реорганизуются по различным причинам, и это нарушает работу устоявшихся и способных команд. Как можно противостоять этому, чтобы сохранить потенциал? Что ж, CMM предлагает процесс сертификации, посредством которого устоявшиеся команды могут получить статус актива, которым нельзя легкомысленно разбрасываться. Детали модели, возможно, менее важны, чем эта институциональная роль. Но в любом случае модель имеет пять уровней: начальный, повторяемый, определенный, управляемый и оптимизирующий, со списком новых вещей, которые нужно добавлять по мере продвижения по иерархии. Таким образом, например, планирование проекта должно быть внедрено для перехода от «начального» к «повторяемому», а экспертные обзоры (peer reviews) — для перехода от «повторяемого» к «определенному».
Еще более распространенным подходом к процессным гарантиям является стандарт ISO 9001. По сути, компания должна документировать свои процессы проектирования, разработки, тестирования, документирования, аудита и управления в целом. В лучшем случае это может обеспечить основу для постепенного улучшения процессов, компании могут отслеживать, что идет не так, возвращаться к источнику, исправлять это и предотвращать повторение. Но очень часто ISO 9001 превращается в упражнение по прикрытию тылов и простановке галочек, которое лишь заменяет хаос более бюрократическим хаосом.
Многие писатели отмечали, что у организаций есть естественный жизненный цикл, так же как и у людей, Йозеф Шумпетер утверждал, что экономические депрессии выполняют ценную общественную функцию, очищая компании, которые прошли свой пик или просто непригодны, точно так же, как пожары омолаживают леса. Несомненно, верно, что успешные компании становятся самодовольными и бюрократичными. Многие инсайдеры выбирают легкую жизнь, в то время как другие, более амбициозные, уходят: раньше говорили, что единственные люди, которые когда-либо уходили из IBM, были хорошими. Слишком быстрый рост также приносит проблемы: инсайдеры Microsoft винят многие проблемы безопасности и другие проблемы продуктов Windows в 1990-х годах на приток десятков тысяч новых сотрудников, многие из которых были мотивированы скорее перспектурой заработать миллионы на опционах и на акции, чем миссией писать хороший код и запускать его на каждом компьютере в известной вселенной.
Цикл корпоративного рождения, смерти и реинкарнации в компьютерной индустрии протекает гораздо быстрее, чем в других отраслях, благодаря сочетанию закона Мура, сетевых эффектов и лихой предпринимательской культуры. Индустрия телекоммуникаций пережила серьезную травму, когда две отрасли слились, и пятнадцатилетние циклы разработки продуктов телефонных компаний столкнулись с пятнадцатимесячными циклами Cisco, Microsoft и других. Индустрия информационной безопасности испытывает то же давление. Команды, которые десятилетиями стабильно работали над контрактами с возмещением затрат для разработки шифраторов или MLS-систем для АНБ, внезапно столкнулись с жестокими технологическими и рыночными силами и были вынуждены создавать совершенно другие вещи. Некоторые преуспели: поставщик MLS TIS переизобрел себя как поставщика межсетевых экранов и антивирусного ПО. Другие потерпели неудачу и исчезли. Таким образом, руководство может усомниться в ценности команды седовласых ветеранов MLS. А экспертные команды могут зависеть от одного-двух ключевых гуру, когда они уходят, чтобы создать стартап, потенциал команды может испариться в одночасье.
Часто упускаемый из виду момент заключается в том, что схемы Assurance, как и криптопротоколы, должны поддерживать отзыв (revocation). CMM был бы более мощным, если бы команды, которые потеряли своих звезд, свой блеск или свою актуальность, также теряли свою аккредитацию. Возможно, нам скорее следует иметь систему ранжирования, используемую в кулинарных гидах, где вы не можете объявить новое заведение «лучшим азиатским рестораном в Сан-Франциско», если не сместите действующего чемпиона. Конечно, если бы сертификация была более скоропортящимся активом, она должна была бы давать большее рыночное преимущество, чтобы компании инвестировали столько же усилий в ее получение. Но в целом система ресторанного гида работает, и академическое рецензирование работает несколько по тому же принципу.

Рост надежности (Assurance Growth)

Еще одним аспектом процессных гарантий является то, что большинство клиентов интересуются не столько командой разработчиков, сколько ее продуктом. Но большая часть программного обеспечения в настоящее время является пакетной, а не заказной, и разрабатывается путем непрерывного эволюционного улучшения, а не в рамках разового проекта. Так что же можно с пользой сказать об уровне Assurance развивающихся продуктов?
Качество такого продукта может достичь равновесия, если скорость внедрения новых багов в продукт будет равна скорости нахождения и удаления старых багов. Но нет никакой гарантии, что это произойдет. (Существуют эффекты второго порядка, такие как старение — когда многократные улучшения делают код настолько сложным, что его базовая надежность и сопровождаемость падают, но ради простоты мы их проигнорируем).
В то время как контроль скорости внедрения багов зависит от описанных выше средств контроля разработки, измерение скорости удаления багов требует других инструментов — моделей того, как надежность программного обеспечения улучшается при тестировании.
О надежности роста известно довольно много, поскольку это интересно гораздо большему количеству людей, чем просто программные инженеры. Там, где тестировщик пытается найти один баг в системе, разумной моделью является распределение Пуассона: вероятность p того, что баг останется не обнаруженным после t статистически случайных тестов, определяется как p = e^(-Et), где E зависит от доли возможных входных данных, на которые он влияет. Таким образом, когда надежность системы доминируется одним багом — как когда мы ищем первый баг в системе или последний — рост надежности может быть экспоненциальным.
Но обширные эмпирические исследования показали, что в больших и сложных системах вероятность того, что t-й тест завершится неудачей, пропорциональна не e^(-Et), а k/t для некоторой константы k. Таким образом, надежность системы растет гораздо медленнее. Это явление было впервые задокументировано в истории багов мейнфреймовых операционных систем IBM и подтверждено во многих других исследованиях. Поскольку вероятность отказа k/t означает среднее время между отказами (MTBF) около t/k, надежность растет линейно со временем тестирования. Этот результат часто формулируется сообществом систем, критичных к безопасности, так: «Если вы хотите, чтобы среднее время между отказами составляло миллион часов, тогда вы должны тестировать (по крайней мере) миллион часов».
Это было одним из главных аргументов против разработки сложных, критически важных систем, которые не могут быть полностью протестированы перед использованием, таких как противоракетная оборона.
Причина поведения k/t была выявлена в работе, а затем было доказано при гораздо более общих предположениях. Модель дает ряд других интересных результатов. При предположениях, которые часто бывают разумными, она является наилучшей из возможных: правило о том, что вам нужен миллион часов тестирования, чтобы получить миллион часов MTBF, неизбежно, с точностью до некоторого постоянного множителя, который зависит от начального качества кода и масштаба тестирования. Это равносильно доказательству версии «Закона Мерфи»: число дефектов, которые переживают процесс отбора, максимизировано.
Эволюционная модель похожа на математические модели эволюции биологического вида под селективным давлением. Роль «багов» играют, грубо говоря, гены, снижающие приспособленность. Но некоторые из последствий заметно отличаются. «Закон Мерфи», гласящий, что количество дефектов, переживающих процесс отбора, максимизировано, может быть плохой новостью для инженера, но это хорошая новость для биологических видов. В то время как тестирование программного обеспечения удаляет минимально возможное количество багов, согласующееся с примененными тестами, биологическая эволюция позволяет виду адаптироваться к изменившейся среде с минимальными затратами ранних смертей и тем временем сохраняет как можно больше разнообразия. Это разнообразие помогает виду пережить будущие экологические шоки.
Например, если на популяцию кроликов охотятся змеи, то они будут отобраны на бдительность, а не на скорость. Разнообразие в скорости сохранится, поэтому, если в окрестностях появятся лисы, средняя скорость бега популяции кроликов резко возрастет под селективным хищничеством. Более формально, фундаментальная теорема естественного отбора гласит, что вид с высокой генетической дисперсией может быстрее адаптироваться к изменяющейся среде. Но когда сэр Рональд Фишер доказал это в 1930 году, он также доказывал, что сложное программное обеспечение будет демонстрировать максимально возможное количество багов, когда вы перенесете его в новую среду.
Эволюционная модель также указывает на фундаментальные ограничения надежности, которые можно получить от повторно используемых программных компонентов, таких как объекты или библиотеки, хорошо протестированные библиотеки просто означают, что общие уровни отказов будут доминироваться новым кодом. Это также объясняет наблюдение сообщества систем, критичных к безопасности, о том, что результаты тестов часто являются плохим индикатором производительности: время отказа, измеряемое тестировщиком, зависит только от начального качества программы, масштаба тестирования и количества тестов, поэтому оно практически не дает дополнительной информации о вероятной производительности программы в другой среде.
Есть также некоторые результаты, которые неожиданны, но очевидны задним числом: например, вклад каждого бага в общий уровень отказов не зависит от того, выполняется ли содержащий его код часто или редко — интуитивно понятно, что код, который выполняется реже, также и тестируется реже. Наконец, как я упоминал ранее, разным тестировщикам часто экономичнее работать над программой параллельно, а не последовательно.
Таким образом, сложные системы становятся надежными только после продолжительного тестирования. Широкое использование массового программного обеспечения позволяет в принципе проводить тщательную отладку, но на практике постоянные новые версии, продиктуемые сетевой экономикой, накладывают серьезные ограничения на то, чего можно разумно ожидать.

Эволюция и гарантии безопасности

Эволюционный рост надежности может быть гораздо хуже для программного инженера, чем для биологического вида, но для инженера по безопасности он еще хуже.
Вместо того чтобы углубляться в подробную математику, давайте рассмотрим упрощенный пример. Предположим, что сложный продукт, такой как Windows Vista, имеет 1 000 000 багов, каждый со средним временем наработки на отказ (MTBF) 1 000 000 000 часов. Предположим, что Ахмед работает в пещере бен Ладена, где его задача — взломать сеть армии США, чтобы получить список информаторов в Багдаде, в то время как Брайан — парень из армии по Assurance, чья задача — остановить Ахмеда. Поэтому он должен узнать о багах раньше, чем Ахмед.
Ахмеду приходится перемещаться, чтобы избежать пакистанской армии, поэтому он может проводить только 1000 часов тестирования в год. У Брайана есть полный исходный код Vista, десятки докторов наук, контроль над коммерческими лабораториями оценки, внутренняя дорожка в CERT, соглашение об обмене информацией с другими странами-членами UKUSA, а также он руководит правительственной схемой, отправляющей консультантов в критические отрасли, такие как энергетика и телекоммуникации, чтобы узнать, как их взломать (простите, проконсультировать их, как защитить свои системы). Поэтому Брайан проводит 10 000 000 часов тестирования в год.
Через год Ахмед находит один баг, а Брайан — 10 000. Но вероятность того, что Брайан нашел баг Ахмеда, составляет всего 1%. Даже если Брайан призовет 50 000 выпускников компьютерных наук в Форт-Мид и заставит их прочесывать исходный код Windows, он все равно будет выполнять только 100 000 000 часов тестирования каждый год. Через десять лет он найдет баг Ахмеда. Но к тому времени Ахмед найдет еще девять, и маловероятно, что Брайан будет знать о всех из них. Хуже того, отчеты о багах Брайана станут таким мощным потоком, что Билл перестанет их исправлять.
Другими словами, на стороне Ахмеда находится термодинамика. Даже умеренно ресурсный атакующий может взломать все, что велико и сложно. Нет ничего, что можно было бы сделать, чтобы остановить это, пока существует достаточно различных уязвимостей безопасности для применения статистики. В реальной жизни уязвимости коррелируют, а не независимы, если 90% ваших уязвимостей — это переполнения стека, и вы внедряете технологию компилятора для их перехвата, то с точки зрения моделирования была только одна уязвимость. Однако новые появляются постоянно. Поэтому, если вы действительно несете ответственность за безопасность армии, вы не можете просто полагаться на большой сложный коммерческий готовый продукт. У вас должны быть мандатные элементы управления доступом, реализованные в чем-то достаточно простом, чтобы это можно было верифицировать. Простота — это ключ к выходу из статистической ловушки.

Оценка систем (Evaluation), Пути вперед

Введение в оценку

Рабочее определение оценки (evaluation) звучит как «процесс сборки доказательств того, что система соответствует или не соответствует предписанной цели по уровню гарантий (assurance target)». Оценка может быть необходима просто для того, чтобы убедить вашего босса в том, что вы завершили работу, но зачастую она требуется для того, чтобы успокоить стороны, которые будут полагаться на эту систему. Фундаментальная проблема заключается в напряжении, возникающем, когда сторона, реализующая защиту, и сторона, полагающаяся на нее, — это разные люди.
Иногда это напряжение простое и вполне управляемое, как в случае, когда вы проектируете охранную сигнализацию по стандартам, установленным страховыми андеррайтерами, и она сертифицируется инспекторами в их лабораториях. Иногда оно все еще заметно, но более сложное, например, при проектировании по правительственным стандартам безопасности, которые пытаются примирить десятки конфликтующих институциональных интересов, или при найме аудиторов вашей компании для проверки системы и доклада боссу о ее пригодности. Ситуация становится еще сложнее, когда вовлечено множество сторон, например, когда вендор смарт-карт хочет получить сертификат оценки от правительственного агентства (которое пытается продвигать использование какой-либо функции, такой как условное депонирование ключей, что не отвечает интересам никого другого), чтобы продать карту банку, который, в свою очередь, хочет использовать ее для перекладывания ответственности за мошенничество на своих клиентов. Это может показаться совершенно нечестным, но при этом ни один из вовлеченных людей не обязательно совершает явно преступные действия. Нечестность может быть эмерджентным свойством, возникающим из-за того, что менеджеры следуют своим личным и ведомственным стимулам.
Например, менеджеры часто покупают продукты и услуги, которые, как они знают, являются неоптимальными или даже дефектными, но которые поставляются крупными и известными поставщиками — просто чтобы минимизировать вероятность быть уволенным, когда что-то пойдет не так. (Раньше, 20 лет назад, говорили, что «никто никогда не был уволен за покупку IBM»). Корпоративные юристы не осуждают это как мошенничество, а хвалят как должную осмотрительность (due diligence). Конечным результатом может стать то, что кто-то, кто полагается на систему — в данном случае клиент банка — не имеет права голоса и ему будет трудно получить компенсацию от банка, вендора, оценщика или правительства, когда что-то пойдет не так.
Другая серьезная и вездесущая проблема заключается в том, что слова «гарантии» (assurance) и «оценка» (evaluation) часто интерпретируются так, что они применяются только к узким техническим аспектам системы, игнорируя системные вопросы, такие как юзабилити, не говоря уже об организационных вопросах, таких как надлежащий внутренний контроль и хорошее корпоративное управление. Директора компаний также хотят гарантий: что направленные процедуры соблюдаются, что в отчетах нет существенных ошибок, что применимые законы соблюдаются, и десятки других вещей. Но многие схемы оценки (особенно Common Criteria) старательно игнорируют человеческие и организационные элементы в системе. Если им вообще уделяется какое-то внимание, оценка этих элементов считается делом ИТ-аудиторов клиента или даже системного администратора, настраивающего конфигурационные файлы.

Тем не менее, далее я сосредоточусь на технической оценке.

Оценки стороной, полагающейся на систему

Удобно разбить оценку на два случая. Первый — когда оценка выполняется стороной, полагающейся на систему, это включает страховые оценки, независимую верификацию и валидацию (IV&V), проводимую NASA для критически важного кода миссий, и предыдущее поколение критериев военной оценки, таких как Оранжевая книга (Orange Book). Второй случай — когда оценка выполняется кем-то другим, кроме полагающейся стороны. В наши дни это часто означает Common Criteria.
Раннее мы обсуждали проблемы, которые волнуют страховщиков в отношении систем физической безопасности, и то, как они подходят к одобрению оборудования для использования с определенными размерами рисков. Сам процесс одобрения достаточно прост: индустрия страхования оперирует лабораториями, где проводятся тесты. Они могут включать фиксированный бюджет усилий (возможно, один человек на две недели, или стоимость в $15,000). Оценщик начинает с довольно четкого представления о том, что должна и не должна делать, например, охранная сигнализация, тратит бюджетированное количество усилий на поиск недостатков и пишет отчет. Лаборатория затем либо одобряет устройство, отклоняет его, либо требует внесения некоторых изменений.
Основной режим отказа этого процесса заключается в том, что он не всегда достаточно хорошо реагирует на прогресс в технологиях атак. В случае с замками высокой безопасности лаборатория может потребовать десяти минут устойчивости к взлому отмычкой и ничего не сказать о бампинге (bumping). Тем не менее, инструменты для бампинга улучшились настолько, что представляют собой серьезную угрозу, да и отмычки стали лучше. Продукт, получивший свой сертификат десять лет назад, теперь может быть легко взломан бампингом (так что стандарт устарел), а также уязвим для взлома отмычкой за 2–3 минуты (так что результат теста тоже устарел). Страховые лаборатории в некоторых странах, таких как Германия, были готовы отзывать сертификации по мере улучшения атак, в других странах, как в США, они неохотно делают это, возможно, из-за страха быть привлеченными к суду.
Я упоминал другую модель оценки — ту, что проводилась с 1985 по 2000 год в Национальном центре компьютерной безопасности США (NCSC) для продуктов компьютерной безопасности, предлагаемых для государственного использования. Эти оценки проводились в соответствии с Оранжевой книгой — Критериями оценки доверенных компьютерных систем (Trusted Computer Systems Evaluation Criteria). Оранжевая книга и ее сопроводительные документы устанавливали ряд классов оценки:

• C1: дискреционный контроль доступа для групп пользователей. По сути, это считается равным отсутствию защиты.
• C2: дискреционный контроль доступа для отдельных пользователей, повторное использование объектов, аудит. C2 соответствует тщательно настроенным коммерческим системам, например, оценки C2 были даны операционным системам мейнфреймов IBM и Windows NT. (Обе они были условными, в случае NT, например, она ограничивалась бездисковыми рабочими станциями).
• B1: мандатный контроль доступа — все объекты имеют метки безопасности, и политика безопасности (что означает Белл-ЛаПадула или ее вариант) обеспечивается независимо от действий пользователя. Маркировка обеспечивается для всей входной информации.
• B2: структурированная защита — как B1, но также должна существовать формальная модель политики безопасности, которая доказуемо согласована с аксиомами безопасности. Должны быть предоставлены инструменты для администрирования системы и управления конфигурацией. TCB (Trusted Computing Base) должна быть правильно структурирована, а ее интерфейс четко определен. Должен быть проведен анализ скрытых каналов (covert channel). Должен быть обеспечен доверенный путь (trusted path) от пользователя к TCB. Должны быть проведены строгое тестирование, включая тестирование на проникновение.
• B3: домены безопасности — как B2, но TCB должна быть минимальной, она должна опосредовать все запросы доступа, она должна быть устойчивой к несанкционированному вмешательству (tamper-resistant) и должна выдерживать формальный анализ и тестирование. Должны существовать механизмы мониторинга и оповещения в реальном времени, и при реализации должны использоваться структурированные методы.
• A1: верификация дизайна. Как B3, но формальные методы должны использоваться для доказательства эквивалентности между спецификацией TCB и моделью политики безопасности.

Класс оценки системы определял, какой диапазон информации мог на ней обрабатываться. Пример, который ранее был приведен, заключался в том, что система, оцененная на B3, может обрабатывать информацию на уровнях Unclassified, Confidential и Secret, или на уровнях Confidential, Secret и Top Secret.
Когда Оранжевая книга была написана, Министерство обороны считало, что реальная проблема заключается в том, что рынки вычислительной техники для обороны слишком малы, что ведет к высоким ценам. Решением было расширение рынка для высокогарантированных вычислений. Таким образом, цель состояла в том, чтобы разработать меры защиты, которые были бы стандартными во всех основных операционных системах, а не дорогостоящим дополнением для плененных правительственных рынков.
Однако бизнес-модель оценок по Оранжевой книге следовала традиционным правительственным рабочим практикам. Правительственный пользователь хотел оценить какой-то продукт, NSA выделяла людей для этого, учитывая традиционную осторожность и задержки гражданской службы, это могло занять два или три года, продукт, в случае успеха, присоединялся к списку оцененных продуктов, а счет оплачивал налогоплательщик. Процессом руководило и контролировало его правительство — сторона, которая собиралась полагаться на результаты оценки, — в то время как вендор был просителем у ворот. Из-за времени, которое занимал процесс, оцененные продукты обычно отставали на одно или два поколения от текущих коммерческих продуктов. Это означало, что оцененные продукты были просто неприемлемы на коммерческих рынках. Рынок оборонных вычислений оставался маленьким, а цены высокими.
Оранжевая книга не была единственной схемой оценки, работавшей в Америке. Я упоминал схему FIPS 140-1 для оценки устойчивости к несанкционированному вмешательству криптографических процессоров, она использует ряд независимых лабораторий в качестве подрядчиков. Подрядчики также используются для Независимой верификации и валидации (IV&V), схемы, созданной Министерством энергетики для систем, используемых в ядерном оружии, а позже принятой NASA для пилотируемых космических полетов, которая имеет много схожих компонентов (по крайней мере, в части ракетостроения). В IV&V существует простая цель оценки — нулевые дефекты. Процесс по-прежнему управляется и контролируется полагающейся стороной — правительством. Подрядчик IV&V является конкурентом компании, которая построила систему, и его оплата привязана к количеству найденных ошибок.
У других правительств были похожие схемы. У канадцев были Критерии оценки доверенных продуктов Канады (CTPEC), в то время как ряд европейских стран разработали Критерии оценки безопасности информационных технологий (ITSEC). Идея заключалась в том, что общая схема оценки поможет европейским оборонным подрядчикам конкурировать с поставщиками из США с их более крупной экономией на масштабе, им больше не придется проходить отдельную сертификацию в Великобритании, Франции, Германии. ITSEC объединил идеи из Оранжевой книги и процессов IV&V в том, что существовало ряд различных уровней оценки, и для всех, кроме самых высоких из этих уровней, работа передавалась на аутсорсинг. Однако ITSEC внесла пагубное нововведение — оценку оплачивал не правительство, а вендор, ищущий оценку своего продукта. Это была попытка убить нескольких зайцев одним выстрелом: сэкономить государственные деньги и одновременно продвигать более конкурентный рынок. Однако вопросы стимулов не были должным образом продуманы.
Это изменение правил мотивировало вендора искать подрядчика по оценке, который обеспечит его продукту самую легкую поездку, будь то задавая меньше вопросов, взимая меньше денег, тратя меньше времени или все вышеперечисленное. Чтобы быть справедливым, потенциал для этого был осознан, и были созданы схемы, посредством которых подрядчики могли получить одобрение в качестве коммерческой лицензированной оценочной организации (CLEF). Угроза того, что CLEF может потерять свою лицензию, должна была компенсировать коммерческое давление на срезание углов.

Common Criteria

Это подготавливает сцену для Common Criteria. Министерство обороны начало осознавать, что Оранжевая книга не облегчает закупки, а подрядчики ненавидели необходимость получать отдельные оценки для своих продуктов в США, Канаде и Европе. После распада Советского Союза в 1989 году бюджеты начали сокращаться, и не было ясно, откуда появятся способные мотивированные противники будущего. Настроение было в пользу радикального сокращения затрат. В конце концов было достигнуто согласие отказаться от национальных схем оценки и заменить их единым стандартом, Common Criteria for Information Technology Security Evaluation.
Работа была в значительной степени завершена в 1994–1995 годах, и европейская модель победила американские и канадские альтернативы. Как и в ITSEC, оценки на всех уровнях, кроме самых высоких, выполняются CLEF и должны признаваться во всех странах-участницах (хотя любая страна может отказаться признать оценку, если скажет, что ее национальная безопасность под угрозой) и вендоры платят за оценки.
Есть некоторые отличия. Самое главное, Common Criteria обладают гораздо большей гибкостью, чем Оранжевая книга. Вместо того чтобы ожидать, что все системы будут соответствовать Белл-ЛаПадула, продукт оценивается на соответствие профилю защиты (protection profile). Существуют профили защиты для операционных систем, систем контроля доступа, устройств пограничного контроля, систем обнаружения вторжений, смарт-карт, систем управления ключами, клиентов VPN и даже систем идентификации мусорных баков — для транспондеров, которые определяют, когда последний раз опорожнялся бытовой мусорный бак. Шатер, безусловно, намного шире, чем с Оранжевой книгой.
Однако любой может предложить профиль защиты и оценить его в лаборатории по своему выбору, поэтому существует много профилей. Дело не в том, что Министерство обороны отказалось от многоуровневой безопасности, сколько в том, что оно попыталось заставить коммерческих ИТ-вендоров использовать систему и для других целей, и таким образом победить пагубные стимулы, описанные выше. Устремлением было создать эффект повозки (bandwagon effect), который приведет к тому, что коммерческий мир в некоторой степени адаптируется к правительственному способу ведения дел.
Его успех был смешанным. Единственный крупный случай, который можно вспомнить, когда крупная фирма использовала оценки в своем общем маркетинге, был Oracle, который начал маркетинговую кампанию после 9/11, описывая свои продукты как «Unbreakable» (Несокрушимые), утверждая, что каждая из его четырнадцати оценок безопасности «представляла собой дополнительные инвестиции в безопасность в размере миллиона долларов». (Эта кампания иссякла после того, как ряд людей нашел способы взломать их продукты). Но было довольно много случаев, когда оценки использовались на более специализированных рынках, мы уже обсуждали терминалы банковских карт (которые оказались легкими для взлома) в ранних частях инженерии безопасности. Индустрия смарт-карт была особым поклонником оценки: в 2007 году существовало не менее 26 профилей защиты смарт-карт и ряд производных профилей для устройств на основе смарт-карт, таких как TPM и устройства создания электронных подписей. Но, возможно, это сработало слишком хорошо. Существует большой выбор, и нелегко понять, что на самом деле означает сертификат оценки. (Мы столкнулись с этой проблемой раньше, когда некоторые криптографические процессоры были сертифицированы как безопасные аппаратные устройства, но их было легко взломать, поскольку они использовались для запуска неподходящего программного обеспечения).

Чтобы подробно обсудить Common Criteria, нам нужно еще немного жаргона.

• Продукт, проходящий тестирование, известен как цель оценки (target of evaluation, TOE). Строгость, с которой проводится examination, — это уровень гарантий оценки (evaluation assurance level, EAL) и может варьироваться от EAL 1, для которого достаточно функционального тестирования, до EAL 7, для которого требуется не только тщательное тестирование, но и формально верифицированный дизайн. Самый высокий уровень оценки, обычно получаемый для коммерческих продуктов, — это EAL4, хотя была одна операционная система смарт-карт на уровне EAL6.
• Профиль защиты (Protection Profile) состоит из требований безопасности, их обоснования и EAL. Предполагается, что он выражен независимым от реализации образом, чтобы обеспечить сопоставимые оценки для различных продуктов и версий. Цель безопасности (Security Target, ST) — это уточнение профиля защиты для данной цели оценки.
• Помимо оценки конкретной цели, можно оценить профиль защиты (чтобы убедиться, что он полон, согласован и технически обоснован) и цель безопасности (чтобы проверить, правильно ли он уточняет данный профиль защиты). При разработке чего-то с нуля идея заключается в том, чтобы сначала создать профиль защиты и оценить его (если подходящий еще не существует), затем сделать то же самое для цели безопасности и, наконец, оценить фактический продукт. Конечным результатом всего этого является реестр профилей защиты и каталог оцененных продуктов.

Профиль защиты должен описывать предположения об окружающей среде, цели и требования защиты (как с точки зрения функции, так и гарантий) и разбивать их на компоненты. Существует стилизованный способ сделать это. Например, FCO NRO — это компонент функциональности (отсюда F), относящийся к коммуникациям (CO), и он относится к неотрекаемости происхождения (non-repudiation of origin, NRO). Другие классы включают FAU (аудит), FCS (поддержка криптографии) и FDP, что означает защиту данных (это не защита данных в европейском праве, а означает контроль доступа, контроль потока информации Белл-ЛаПадула и связанные с ними свойства).
Существуют каталоги угроз, таких как T.Load Mal — «Сбой загрузки данных: злоумышленник может злонамеренно генерировать ошибки в данных настройки, чтобы скомпрометировать функции безопасности TOE», предположений, таких как A.Role Man — «Управление ролями: управление ролями для TOE выполняется безопасным образом» (другими словами, разработчики, операторы и так далее ведут себя надлежащим образом), организационных политик, таких как P.Crypt Std — «Криптографические стандарты: криптографические сущности, аутентификация данных и функции одобрения должны соответствовать стандартам ISO и связанным отраслевым или организационным стандартам», целей, таких как O.Flt Ins — «Вставка неисправностей: TOE должна быть устойчива к повторным зондированиям посредством вставки ошибочных данных», требований к гарантиям, таких как ADO DEL.2 — «Обнаружение модификации: разработчик должен документировать процедуры доставки TOE или ее частей пользователю».
Я упоминал, что профиль защиты будет содержать обоснование. Обычно оно состоит из таблиц, показывающих, как каждая угроза контролируется одной или несколькими целями, и в обратном направлении, как каждая цель обусловлена некоторой комбинацией угроз или предположений об окружающей среде, а также сопроводительными объяснениями. Оно также будет обосновывать выбор уровня гарантий и требования к силе механизма.
Самый быстрый способ понять суть этого, вероятно, — прочитать несколько существующих профилей. Вы поймете, что качество сильно варьируется. Например, профиль защиты Eurosmart для смарт-карт в значительной степени касается поддержания конфиденциальности дизайна чипа путем наложения NDA на подрядчиков, уничтожения отходов и так далее, в то время как на практике большинство атак на смарт-карты использовали зондирование или атаки по электропитанию, для которых знание маски чипа не имело значения. Другим примером невпечатляющего профиля защиты является профиль для автоматических диспенсеров наличных, который написан на управленческом языке, полностью с клип-артом, «решил не включать никакую политику безопасности» и упускает даже многие из проблем, которые были хорошо известны и задокументированы, когда он был написан в 1999 году. Действительно, в нем говорится, что он полагается на разработчика в документировании уязвимостей и требует, чтобы «оценщик определил, что TOE устойчива к атакам проникновения, выполняемым злоумышленником, обладающим умеренным потенциалом атаки». Лучшим примером является более поздний профиль, разработанный правительством Германии для карт медицинских работников — карт, используемых врачами и медсестрами для входа в больничные компьютерные системы. Этот профиль подробно рассматривает возможные угрозы, связанные с физическим вмешательством, анализом электропитания, злоупотреблением функциональностью и так далее, и систематически связывает механизмы защиты с целями контроля.
Итак, первый вопрос, который вы должны задать, когда вам говорят, что у какого-то продукта есть оценка Common Criteria: «на основе какого профиля защиты?» Это секретный дизайн, который будет устойчив к «умеренной атаке», или он был оценен на основе чего-то тщательного, что было продумано людьми, которые знают, что они делают? Интересная вещь заключается в том, что все три профиля, которые я упомянул в вышеприведенном абзаце, предназначены для оценки на уровне EAL4+ — так что не номинальный уровень CC говорит вам о чем-то, а детали PP.
Критерии действительно говорят, что «тот факт, что ИТ-продукт был оценен, имеет смысл только в контексте свойств безопасности, которые были оценены, и методов оценки, которые использовались», но далее говорится, что как «Органы оценки должны тщательно проверять продукты, свойства и методы, чтобы определить, что оценка обеспечит значимые результаты», так и «покупатели оцененных продуктов должны тщательно учитывать этот контекст, чтобы определить, полезен ли оцененный продукт и применим ли он к их конкретной ситуации и потребностям». Так кто же на самом деле несет ответственность? Что ж, мы обнаруживаем, что «CC не рассматривает административные и правовые рамки, в которых критерии могут применяться органами оценки» и что «Процедуры использования результатов оценки в аккредитации находятся вне сферы действия CC».
Common Criteria иногда могут быть полезны для инженера по безопасности в том смысле, что они дают вам обширный список вещей, которые нужно проверить, и структура также может помочь в отслеживании всех различных угроз и обеспечении того, чтобы все они были рассмотрены систематически (в противном случае очень легко, чтобы одна из них была забыта в массе деталей и проскользнула мимо). Что люди часто делают, однако, так это находят профиль защиты, который кажется разумно близким к тому, что они пытаются сделать, и просто используют его как контрольный список без дальнейших размышлений. Если вы выберете профиль, который плохо соответствует, или один из старых и расплывчатых, вы напрашиваетесь на неприятности.

Что Common Criteria не делают

Также важно понимать ограничения Критериев. Документы утверждают, что они не касаются мер административной безопасности, ни «технических физических» аспектов, таких как Emsec, ни криптографических алгоритмов, ни методологии оценки (хотя существует сопроводительный том об этом), ни того, как стандарты должны использоваться. Они утверждают, что не предполагают никакой конкретной методологии разработки (но затем продолжают предполагать водопадный подход). Есть кивок в направлении эволюции политики в ответ на опыт, но повторная оценка продуктов объявляется находящейся вне сферы действия. О, и нет требования доказательств того, что профиль защиты соответствует реальному миру и я видел несколько таких, которые старательно игнорировали опубликованные работы по соответствующим уязвимостям. Другими словами, Критерии избегают всех сложных и интересных частей инженерии безопасности и могут легко стать хартией для тех, кто выбирает только вишенки (cherry pickers).
Наиболее распространенная конкретная критика (помимо затрат и бюрократии) заключается в том, что Критерии слишком сосредоточены на технических аспектах дизайна: такие вещи, как юзабилити, почти игнорируются, а взаимодействие административных процедур фирмы с техническими средствами защиты замалчивается как находящееся вне сферы действия.
Другая распространенная критика заключается в том, что Критерии плохо справляются с изменениями. У многих коммерческих продуктов есть оценка, которая по сути бессмысленна: операционные системы, такие как Windows и Linux, были оценены, но в очень ограниченных конфигурациях (как правило, рабочая станция без сетевого подключения или съемных носителей — где все, что говорит оценка, это то, что есть процесс входа в систему и что контроль доступа к файловой системе работает). Продукты с обновлениями, такие как Windows с его ежемесячными патчами безопасности, находятся вне сферы действия. Это может привести к небезопасности напрямую: отмечали, что первая реальная атака типа распределенного отказа в обслуживании использовала больничные ПК, так как процесс оценки и аккредитации, используемый в то время, вынуждал больницы использовать устаревшую и, таким образом, небезопасную конфигурацию.
На самом деле очень часто, когда вы читаете мелкий шрифт PP, вы обнаруживаете, что были оценены только некоторые очень базовые функции продукта. Вендор мог оценить загрузочный код, но оставил большую часть операционной системы вне сферы действия. Это относится не только к оценкам CC, но и к FIPS-140, ранее рассказывалось, как IBM 4758 была оценена правительством США по самому высокому стандарту физической устойчивости к вмешательству, и все же ее было легко взломать. Оценщики смотрели только на устойчивую к вмешательству платформу, в то время как злоумышленники также смотрели на программное обеспечение, которое на ней работало.
Еще одна фундаментальная проблема заключается в том, что Критерии ориентированы на технологии, тогда как в большинстве приложений именно бизнес-процессы должны определять решения о защите. Технические механизмы не должны использоваться, когда воздействие меньше, чем стоимость его контроля, или когда процедурные средства защиты дешевле. Помните, почему Сэмюэл Морс победил десятки других людей, которые мчались строить электрические телеграфы в начале девятнадцатого века. Они пытались строить модемы, чтобы они могли доставлять текст с одного конца на другой, Морс понял, что при доступной тогда технологии дешевле обучать людей быть модемами.
За последнее десятилетие, должно быть, Росс Андерсон прошел полдюжины споров о том, были ли механизмы защиты правильно спроектированы или реализованы, и в которых Common Criteria были каким-то образом задействованы. Ни в одном из них их подход не оказался удовлетворительным. (Возможно, это потому, что его вызывали только тогда, когда что-то идет не так — но его опыт все же указывает на отсутствие устойчивости в процессе). Существуют не только технические ограничения и ограничения сферы действия, существуют также пагубные стимулы и политические провалы.

Коррупция, манипуляции и инерция

Оценки Common Criteria выполняются CLEF — подрядчиками, которые являются «Коммерческими лицензированными оценочными организациями» (Commercial Licensed Evaluation Facilities). Они лицензируются местным агентством сигнальной разведки (NSA в Америке или ее аналогами в Великобритании, Канаде, Франции, Германии, Испании, Нидерландах, Австралии, Новой Зеландии и Японии). Одним из следствий этого является то, что их сотрудники должны иметь допуски. В результате CLEF довольно сильно зависят от местных шпионов.
Один вопиющий пример произошел в британской Национальной службе здравоохранения (NHS). Служба согласилась, под давлением врачей, шифровать трафик в сети службы здравоохранения, служба сигнальной разведки GCHQ дала понять, что она хочет, чтобы использовались продукты с условным депонированием ключей. Были организованы испытания, одно из них использовало коммерческое программное обеспечение шифрования от датского поставщика, которое не имело условного депонирования ключей и стоило £3,000, в то время как другое использовало программное обеспечение от британского оборонного подрядчика, которое имело условное депонирование ключей и стоило £100,000. К смущению GCHQ, датское программное обеспечение работало, но британский поставщик не производил ничего, что было бы пригодно для использования. Ситуация была быстро исправлена тем, что компания с лицензией CLEF провела оценку испытаний. В своем отчете они утверждали ровно обратное: что программное обеспечение с депонированием работало отлично, в то время как иностранный продукт имел всевозможные проблемы. Возможно, CLEF просто сказали, что написать, или, возможно, сотрудники написали то, что, как они знали, GCHQ хотела прочитать.
Вторая проблема заключается в том, что, поскольку именно вендор платит CLEF, вендор может искать CLEF, который обеспечит ему легкую поездку в техническом плане, или который будет следовать его политической линии. В контексте исландской базы данных о здоровье, которую выше, ее промоутеры хотели обезвредить критику со стороны врачей по поводу ее проблем с конфиденциальностью, поэтому они наняли британский CLEF, чтобы написать для них профиль защиты. Этот профиль просто повторял, на жаргоне Критериев, первоначальный дизайн и заявления промоутеров, он старательно избегал замечать недостатки в этом дизайне, которые уже были задокументированы и даже обсуждались по исландскому ТВ.
Иногда профили защиты могут быть надежными, но то, как они сопоставляются с приложением, — нет. Например, вендоры смарт-карт лоббировали европейские правительства, чтобы принять законы, обязывающие бизнес признавать цифровые подписи, сделанные с использованием смарт-карт, ряд профилей защиты был duly написан для смарт-карты, функционирующей как «Безопасное устройство создания подписи» (Secure Signature-Creation Device). Но главная проблема в таком приложении — это ПК, который отображает гражданину материал, который, как он думает, он подписывает. Поскольку эта проблема слишком сложна, она исключается, и конечным результатом будет «безопасная» (в смысле неотрекаемая) подпись на том, что вирус или троян на вашем ПК отправил на вашу смарт-карту. Электронные подписи не взлетели, ни один разумный человек не согласится быть связанным любой подписью, которая, как кажется, была сделана его смарт-картой, независимо от того, действительно ли он ее сделал. (Для сравнения, в мире бумаги поддельная рукописная подпись полностью недействительна и не может связать никого). В этом случае жадность вендоров и наивность законодателей разрушили рынок, на котором они надеялись получить прибыль.
Инсайдеры придумывают еще более изощренные способы манипулирования системой. Хороший пример здесь приходит из того, как французы обошли британское и немецкое возражение к электронному тахографу на основе смарт-карт. Французы написали расслабленный профиль защиты и отправили его британскому CLEF для оценки. CLEF была армейской софтверной компанией и, каковы бы ни были их знания о MLS, они ничего не знали о смарт-картах. Но это не привело к тому, что они отказались от бизнеса. Они также не знали, что правительство Великобритании выступало против одобрения профиля защиты (если бы они знали, они бы, несомненно, пошли в ногу). Таким образом, Великобритания оказалась перед выбором между принятием дефектных стандартов безопасности дорожного движения как свершившегося факта или подрывом доверия к Common Criteria. В конце концов, никто в Лондоне не имел желания оспаривать оценку, восемь лет спустя старые бумажные тахографы начали заменяться новыми, менее безопасными, электронными.
Что касается организационных аспектов, системы гарантий, основанные на процессах, терпят неудачу, если аккредитованные команды не теряют свою аккредитацию, когда они теряют свой блеск. Это явно относится к CLEF. Даже если бы CLEF лицензировались органом, независимым от разведывательного сообщества, многие из них ухудшатся по мере того, как ключевые сотрудники уйдут или навыки не будут поспевать за технологиями и поскольку клиенты ищут более легкие оценки, неизбежно будут как коррупция, так и инфляция оценок. Как говорил Росс Андерсон: «Тем не менее, в настоящее время я не вижу никакого пригодного для использования механизма, посредством которого практик, обладающий очень вескими доказательствами некомпетентности (или даже нечестности), может бросить вызов CLEF и заставить ее удалить из списка. В отсутствие санкций за неправильное поведение, стимулом для CLEF будет гонка на дно и конкуренция за то, чтобы обеспечить вендорам легкую поездку».
Я описал ранее, как в конце 2007 года обнаружили, что устройства ввода PIN-кода, сертифицированные как безопасные как VISA, так и Common Criteria, были чем угодно, только не безопасными, действительно, профиль защиты, на основе которого они были оценены, не мог быть выполнен. После сообщения об уязвимости вендорам, VISA, торговой ассоциации банкиров и GCHQ, мы указали, что это был провал не только лабораторий, которые оценили эти конкретные устройства, но и системный провал. Что, мы потребовали, VISA и GCHQ предлагают с этим сделать? Ответом, как оказалось, было ничего. VISA отказалась отозвать свою сертификацию, и правительство Великобритании сказило, что, поскольку оценка не была зарегистрирована у них, это не их проблема. Поставщики могут продолжать описывать дефектный терминал как «оцененный по CC» и даже «одобренный по CC», до тех пор, пока они не называют его «сертифицированным по CC» или «сертифицированным в соответствии с Соглашением о признании Common Criteria (CCRA)». Это кажется серьезной проблемой с брендом CC. Он будет продолжать штамповаться на паршивых продуктах в обозримом будущем.
Итак, лучший совет, который я могу предложить, таков. Когда вам представляют продукт безопасности, вы всегда должны учитывать, лжет ли продавец или ошибается, и как. Common Criteria должны были исправить эту проблему, но они этого не делают. Когда вам представляют оцененный продукт, вы должны потребовать, какие уязвимости были сообщены или обнаружены с момента проведения оценки. (Получите это в письменном виде). Затем внимательно посмотрите на профиль защиты: проверьте, соответствует ли он тому, что вам действительно нужно. (Обычно это не так — он защищает вендора, а не вас). Не ограничивайте свой скептицизм чисто техническими аспектами: спросите, как он был манипулирован и кем, был ли CLEF, который оценил профиль, нечестным или некомпетентным и какое давление от какого правительства могло быть применено за кулисами.
Вы также должны учитывать, как ваши права размываются сертификатом. Например, если вы используете неоцененный продукт для создания цифровых подписей, и поддельная подпись появляется, которую кто-то пытается использовать против вас, вы можете разумно ожидать оспорить доказательства, убедив суд приказать раскрыть полную документацию вашим экспертам-свидетелям. Сертификат Common Criteria может сделать суд гораздо менее готовым приказать раскрытие и, таким образом, может нанести ущерб вашим правам.
Циник мог бы предположить, что именно поэтому в коммерческом мире именно вендоры продуктов, которые предназначены для передачи ответственности (таких как смарт-карты), или для удовлетворения требований должной осмотрительности (таких как межсетевые экраны), наиболее энтузиастичны по отношению к Common Criteria. Действительно закаленный циник мог бы указать на то, что после распада Советского Союза агентства оправдывают свое существование экономическим шпионажем, и страны-участницы Common Criteria предоставляют большинство интересных целей. Фальшивая оценка продукта в США, который продается по всему миру, может скомпрометировать 250 миллионов американцев, но поскольку она также скомпрометирует 400 миллионов европейцев, баланс преимуществ лежит в обмане. Баланс еще сильнее с малыми странами, такими как Великобритания и Нидерланды, у которых меньше граждан для защиты и больше иностранцев для атаки. Кроме того, агентства получают похвалы (и бюджет) за иностранные секреты, которые они крадут, а не за местные секреты, которые иностранцы не смогли украсть.
Так что экономист вряд ли будет доверять оценке Common Criteria. Возможно, стоит рассматривать их как нечто вроде резинового костыля. Такое устройство имеет всевозможные применения, от завоевания симпатий судьи до выманивания денег у доверчивого правительства и удара людей по голове. (Просто не пытайтесь положить на него серьезный вес!)
К счастью, экономика, также должна ограничить внедрение Критериев секторами, где официальная сертификация, какой бы нерелевантной, ошибочной или лживой она ни была, предлагает некоторое конкурентное преимущество.

Пути вперед

В своей классической книге «Мифический человеко-месяц» Брукс убедительно утверждает, что не существует «серебряной пули» для решения проблем программных проектов, которые выполняются с опозданием и превышают бюджет. Легкие части проблемы, такие как разработка языков высокого уровня, в которых программисты более продуктивны, были сделаны. Это убирает большую часть случайной сложности программирования, оставляя внутреннюю сложность приложения. Я обсуждал это в ранних частях в общем контексте методологии разработки систем, вышеизложенное обсуждение должно убедить вас, что точно то же самое относится и к проблеме гарантий и, особенно, оценки.
Более реалистичный подход к оценке и гарантиям рассматривал бы не только технические функции продукта, но и то, как он ведет себя в реальном использовании. Юзабилити игнорируется Common Criteria, но в реальности это все важно, правительственная система электронной почты Великобритании, которая требовала от пользователей перезагружать их ПК всякий раз, когда они меняли отсеки, настолько расстраивала пользователей, что они заключали неформальные соглашения, чтобы помещать все в общие отсеки — по сути, тратя инвестиции в девять фигур. (Официальная секретность, несомненно, продолжит защищать виновных сторон от наказания). Критические функции, которые мы обсуждали в контексте систем бухгалтерского учета в одной из частей, которые предназначены для ограничения эффектов человеческой слабости, также критичны. В большинстве приложений необходимо предполагать, что люди всегда неосторожны, обычно некомпетентны и иногда нечестны.
Также необходимо столкнуться с фактом больших, богатых функциями программ, которые часто обновляются. Экономику нельзя просто пожелать. Схемы оценки и гарантий, такие как Common Criteria, ISO9001 и даже CMM, пытаются втиснуть очень изменчивую и конкурентную индустрию в бюрократическую смирительную рубашку, чтобы предоставить покупателям иллюзию стабильности. Но учитывая, как работает индустрия, лучшее, что могут сделать люди, это сплотиться вокруг брендов, таких как IBM в 70-х и 80-х, и Microsoft сейчас. Создание и поддержание этих брендов включает в себя огромные рыночные силы, и безопасность играет незначительную роль.
Я дал вам достаточно подсказок к тому, как обмануть систему и выдать паршивую систему за безопасную — по крайней мере, достаточно долго, чтобы проблема стала чьей-то еще. В оставшейся части данной статьи я буду предполагать, что вы делаете честную попытку защитить систему и хотите снижения рисков, а не должной осмотрительности или какого-то другого вида перекладывания ответственности.
Тем не менее, все еще есть много систем, где владелец системы проигрывает, если безопасность терпит неудачу, мы видели ряд из них выше (ядерное командование и контроль, платное ТВ, счетчики предоплаты за коммунальные услуги и тд.) и они предоставляют много интересных инженерных примеров.

Враждебный обзор

Когда вы действительно хотите, чтобы свойство защиты выполнялось, жизненно важно, чтобы дизайн подвергся враждебному обзору. В конце концов это произойдет, и лучше, если это будет сделано до того, как система будет развернута. Как мы видели в одном случае за другим, мотивация атакующего почти все важна, дружественные обзоры людьми, которые хотят, чтобы система прошла, по сути бесполезны по сравнению с вкладом людей, которые серьезно пытаются ее взломать.
Классические способы проведения враждебного обзора — контрактный и конфликтный. Примером контрактного подхода была программа Независимой верификации и валидации (IV&V), используемая NASA для пилотируемых космических полетов, подрядчики нанимались для прочесывания кода и получали бонус за каждую найденную ошибку. Примером конфликтного подхода была оценка ядерного командования и контроля, где Национальные лаборатории Сандия и NSA соревновались за то, чтобы найти ошибки в дизайнах друг друга.
Одним из способов объединить два является просто нанять нескольких экспертов из разных консалтинговых фирм или университетов и отдать повторный бизнес тому, кто наиболее заметно находит ошибки и улучшает дизайн. Другой способ — иметь несколько различных органов аккредитации: я упоминал как системы голосования в США проверяются независимо в каждом штате, и в те дни, до того как стандарты были навязаны такими организациями, как VISA и SWIFT, банки строили локальные платежные сети, каждая из которых имела свой дизайн, проверяемый своими собственными аудиторами. Однако ни один из подходов не является непогрешимым, есть несколько действительно ужасных устаревших систем голосования и банковских систем.

Свободное и открытое программное обеспечение

Движение за свободное и открытое программное обеспечение расширяет философию открытости от архитектуры к деталям реализации. Многие продукты безопасности имеют общедоступный исходный код, первым из которых, вероятно, была программа шифрования электронной почты PGP. Операционная система Linux и веб-сервер Apache также являются открытыми и на них полагаются многие люди для защиты информации. Также существует стремление принять открытый исходный код в правительстве.
Программное обеспечение с открытым исходным кодом не является полностью недавним изобретением, в ранние дни вычислений большинство поставщиков системного программного обеспечения публиковали свой исходный код. Эта открытость начала исчезать в начале 1980-х годов, когда давление судебных исков привело IBM к принятию политики «только объектный код» для своего программного обеспечения мейнфреймов, несмотря на горькую критику со стороны сообщества пользователей. Маятник недавно начал качаться обратно, и IBM является одним из столпов открытого исходного кода.
Существует ряд веских аргументов в пользу открытого программного обеспечения и несколько против. Во-первых, если каждый в мире может проверять и играть с программным обеспечением, то ошибки, вероятно, будут найдены и исправлены, в знаменитой фразе Рэймонда, «Для многих глаз все ошибки неглубоки». Это особенно верно, если программное обеспечение поддерживается в совместных усилиях, как Linux и Apache. Также может быть труднее вставить бэкдоры в такой продукт.
Стандартный аргумент оборонного подрядчика против открытого исходного кода заключается в том, что, когда программное обеспечение становится большим и сложным, может быть мало или вообще не будет способных мотивированных людей, изучающих его, и серьезные уязвимости могут не быть найдены годами. Например, ошибка программирования в версиях PGP 5 и 6 позволяла злоумышленнику добавить дополнительный ключ условного депонирования без знания держателя ключа, это было вокруг годами, прежде чем это было замечено. Были также бэкдорные «пароли обслуживания» в продуктах, таких как sendmail, которые сохранялись годами, прежде чем они были удалены.
Беспокойство заключается в том, что могут быть атакующие, которые достаточно мотивированы, чтобы тратить больше времени на поиск ошибок или эксплуатируемых функций в опубликованном коде, чем сообщество рецензентов. Во-первых, может быть недостаточно рецензентов для многих открытых продуктов, так как типичный волонтер находит разработку кода более полезной, чем поиск эксплойтов. Много разработки с открытым исходным кодом делается студентами, которые находят, что это помогает им получить хорошие работы позже, если они могут указать на какой-то компонент систем работодателя, который они помогли разработать, возможно, это не было бы так полезно, если бы все, на что они могли указать, была коллекция отчетов об ошибках, которые заставили обновления безопасности. Во-вторых, разные тестировщики находят разные ошибки, поскольку их фокус тестирования различен, так что вполне возможно, что даже после того, как продукт выдержал 10,000 часов общественного исследования, иностранное разведывательное агентство, которое инвестировало всего 1000 часов, может найти новую уязвимость. Учитывая цитируемые модели роста надежности, вероятности достаточно легко вычислить.
Другие аргументы включают наблюдение, что активные проекты с открытым исходным кодом добавляют функциональность и функции с головокружительной скоростью по сравнению с закрытым программным обеспечением, что может открыть неприятные взаимодействия функций, что такие проекты могут не достичь консенсуса о том, что безопасность пытается достичь и что есть особые случаи, такие как защита смарт-карт от различных атак, где проприетарный алгоритм шифрования, встроенный в аппаратное обеспечение чипа, может заставить атакующего потратить значительно больше усилий на обратную разработку.
Так где же баланс преимуществ? Влиятельный анализ Эрика Рэймонда экономики программного обеспечения с открытым исходным кодом предполагает, что есть пять критериев того, получит ли продукт выгоду от подхода с открытым исходным кодом: где он основан на общих инженерных знаниях, а не на проприетарных техниках, где он чувствителен к сбоям, где ему требуется экспертная оценка для верификации, где он достаточно критичен для бизнеса, что пользователи будут сотрудничать в поиске и удалении ошибок и где его экономика включает сильные сетевые эффекты. Безопасность проходит все эти тесты.
Некоторые люди утверждали, что в то время как открытость помогает защитникам находить ошибки, чтобы они могли их исправить, она также поможет атакующим находить ошибки, чтобы они могли их эксплуатировать. Поможет ли атакующим или защитникам больше? В 2002 году было доказано, что при стандартной модели роста надежности открытость помогает атаке и защите одинаково. Таким образом, будет ли открытый или проприетарный подход работать лучше в данном приложении, будет зависеть от того, насколько и как это приложение отходит от стандартных предположений, например, о независимых уязвимостях. В качестве примера, исследование ошибок безопасности, найденных в операционной системе OpenBSD, показало, что эти ошибки были значительно коррелированы, что предполагает, что открытость там была хорошей вещью.
На самом деле существует долгая история инженеров по безопасности в различных дисциплинах, обращенных в открытость. Давняя мудрость Огюста Керкгоффса заключалась в том, что криптографические системы должны быть спроектированы таким образом, чтобы они не были скомпрометированы, если противник узнает используемую технику. Дебаты о том, должны ли слесари обсуждать уязвимости в замках, начались в викторианские времена. Ученый в области права и экономики Питер Свайр объяснил, почему правительства по своей природе менее склонны принимать раскрытие: хотя конкурентные силы заставляют даже Microsoft открывать много своего программного обеспечения по причинам совместимости и доверия, правительственные агентства играют в другие игры (такие как расширение своих бюджетов и избегание смущения). Тем не менее, аргументы безопасности начали преобладать в некоторых кругах: от осторожных начинаний примерно в 1999 году, Министерство обороны США начало принимать открытый исходный код, в частности, через проект SELinux.
Так что, хотя открытый дизайн не является ни необходимым, ни достаточным, он часто будет полезен. Важные вопросы заключаются в том, сколько усилий было потрачено способными людьми на проверку и тестирование того, что вы построили — и говорят ли они вам все, что находят.

Полуоткрытый дизайн

Там, где полностью открытый дизайн невозможен, вы часто все еще можете получить выгоды, выбрав частично открытый. Например, архитектурный дизайн может быть опубликован, даже если некоторые детали реализации не являются. Примеры, которые мы видели, включают протокол банковских смарт-карт, системы ядерного командования и контроля и механизм SPDC в Blu-Ray.
Другим подходом к полуоткрытому дизайну является использование открытой платформы и создание проприетарных компонентов поверх нее. Наиболее известным примером здесь может быть OS/X от Apple, которая сочетает операционную систему OpenBSD с проприетарными мультимедийными компонентами. В других приложениях проприетарный, но широко используемый продукт, такой как Windows или Oracle, может быть «достаточно открытым». Предположим, например, что вы беспокоитесь о правовой атаке. Если в суде идет спор о том, была ли система безопасной во время оспариваемой транзакции, то вместо того, чтобы заставлять противоположных экспертов прочесывать код, вы можете положиться на историю раскрытых уязвимостей, патчей и атак. Таким образом, мы обнаруживаем, что все больше и больше банкоматов используют Windows в качестве платформы (хотя версия, которую они используют, имеет много ненужных вещей, вырезанных).

Penetrate-and-Patch, CERTs и Bugtraq

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

1. Вендор предпочел бы, чтобы ошибки не находились, чтобы сэкономить расходы на исправление.
2. Средний клиент может предпочесть то же самое, ленивые клиенты часто не патчат и заражаются в результате. (Пока их ISP не отключит их за отправку спама, они могут не заметить или не заботиться).
3. Типичный исследователь по безопасности хочет ответственный способ раскрытия своих открытий, чтобы он мог дать вендорам разумный период времени для выпуска патча, прежде чем он опубликует свою конференционную статью, поэтому он обычно отправляет отчет в местную группу реагирования на компьютерные чрезвычайные ситуации (CERT), которая, в свою очередь, уведомит вендора и опубликует уязвимость через 45 дней.
4. Разведывательные агентства хотят узнать об уязвимостях быстро, чтобы они могли быть эксплуатированы до выпуска патча. (Многие CERT финансируются агентствами и имеют допущенный персонал).
5. Некоторые хакеры раскрывают уязвимости в списках рассылки, таких как bugtraq, которые не накладывают задержку, это может заставить вендоров программного обеспечения выпускать экстренные патчи вне обычного цикла.
6. Компании по безопасности выигрывают от существования не патченных уязвимостей в том, что они могут использовать свои межсетевые экраны для фильтрации атак с их использованием, и антивирусное программное обеспечение на ПК их клиентов также часто может попытаться перехватить такие атаки. (Symantec хостит список bugtraq).
7. Крупные компании не любят экстренные патчи, и большинство правительственных департаментов тоже, так как процесс тестирования нового патча против критических систем предприятия и его развертывания дорог.

В 1990-х годах дебатами руководили люди, которые были расстроены тем, что вендоры программного обеспечения оставляли свои продукты не патченными на месяцы или даже годы. Это была одна из причин, по которой был создан список bugtraq, это затем привело к дебатам об «ответственном раскрытии» с различными предложениями о том, сколько времени на передышку исследователь должен дать вендору. Система CERT с 45-дневной задержкой возникла из этого. Она дает вендорам сильный стимул иметь внимательное средство сообщения об ошибках, в ответ они получают достаточно времени, чтобы правильно протестировать исправление перед его выпуском, исследователи получают кредиты, чтобы поместить в свои резюме и пользователи получают исправления ошибок одновременно с отчетами об ошибках и крупные компании имеют регулярные обновления или сервисные пакеты, для которых их корпоративные клиенты могут планировать.
Является ли эта система лучшей, которую мы могли бы получить? Недавно цикл патчей стал предметом изучения экономистами по безопасности. На Воркшопе по экономике информационной безопасности в 2004 году развернулись дебаты между Эриком Рескорла, который утверждал, что, поскольку ошибок много и они не коррелированы, и поскольку большинство эксплойтов используют уязвимости, обратно разработанные из существующих патчей, должно быть минимальное раскрытие. Ашиш Арора утверждал, что, как с теоретической, так и с эмпирической точек зрения, угроза раскрытия была необходима, чтобы заставить вендоров патчить. Были некоторые инновации, в частности, введение по сути автоматических обновлений для массовых пользователей и создание фирм, которые делают рынки уязвимостей, и у нас есть еще некоторые исследовательские данные, в частности, тот факт, что ошибки в OpenBSD и некоторых других системах коррелированы. По большому счету, текущий способ ведения дел кажется разумным и стабильным.

Образование

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

Резюме (Summary)

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

Жизнь сложна. Успех означает справляться с ней. Слишком много жалоб на нее — это путь к неудаче.