Мифы вокруг кибербезопасности

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

Мифы часто содержат в себе знания или идеи, которые появились в результате проб и ошибок и были сформулированы в доступном для восприятия виде. Со временем мифы могут меняться с учетом нового практического опыта и привычек. Как заметил Джозеф Кэмпбелл, мифы несут в себе две функции, одна из которых состоит в том, чтобы «представить космологию, образ вселенной», а другая – чтобы «подтвердить и поддержать установленный порядок» [1]. Остановимся на четырех мифах, которые встречаются как в популярной литературе, так и в технических материалах.

Миф 1: чем больше уровней безопасности, тем лучше

Базовые требования безопасности – это целостность, конфиденциальность и готовность, определенные и сбалансированные в соответствии с конкретными условиями. В итоге стратегия многоуровневой защиты, или «защиты в глубину», означает сохранение «бриллиантов короны» за счет строго соблюдаемых логических и физических уровней, реализуемых механизмами обеспечения безопасности (принятый в киберпространстве эквивалент физических стен и рвов) [2].

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

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

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

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

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

В 1984 году Кен Томпсон, выступая с лекцией по случаю вручения ему премии Тьюринга, рассказал о факте использования компилятора с языка Си для внедрения в систему троянского коня [3]. В 2005 году программное обеспечение управления правами на цифровые носители Sony BMI устанавливалось в тот момент, когда пользователи воспроизводили некоторые музыкальные компакт-диски в Windows-системах [4], в результате система становилась более уязвимой к действиям хакеров. Томпсон пришел к заключению: «Нельзя доверять коду, если он полностью не создан вами». К этому можно добавить: «Вы никогда не можете полностью доверять своему собственному коду».

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

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

Сложность в этом примере дает хакерам преимущество и обеспечивает существенную асимметрию, о которой еще Сунь Цзы говорил применительно к войне: атакующему нужно использовать только одно уязвимое место противника [5], а чтобы быть неуязвимым, защищающийся должен быть готов противостоять по всем направлениям, известным или нет, уже существующим или тем, которые могут быть созданы атакующим с применением небольших хитростей. Очевидно, что реализовать все это на практике невозможно. Например, когда Microsoft разрабатывала Windows Vista, безопасности этой ОС придавалось особое значение, кроме того, компания провела расширенное бета-тестирование. И все-таки в течение трех месяцев после выпуска этой системы Microsoft сделала сообщения об обнаружении пяти уязвимых мест в защите, два из которых, по мнению специалистов компании, имели высокую степень риска [6]. Однако таких изъянов могло быть и больше. Итог таков: эта ОС по-прежнему остается уязвимой, несмотря на все меры предосторожности, предпринятые разработчиком.

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

Еще один интересный подход к обучению состоит в том, чтобы показать, что добавление очередного уровня безопасности на самом деле предоставляет нарушителю альтернативный маршрут для доступа в систему. Так, например, происходит в случае системы обнаружения вторжений (Intervention Detection System, IDS), которая содержит уязвимый пароль системного уровня, позволяющий выполнять «поддержку» извне системы.

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

Миф 3: эффективная безопасность обязательно обременительна

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

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

Например, аутентификация Kerberos уязвима, поскольку позволяет подобрать пароль «методом грубой силы» [7], и организации, применяющие Kerberos, пытаются компенсировать эту уязвимость путем использования сложных паролей, содержащих заглавные буквы, специальные символы и т.д. 

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

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

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

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

Миф 4: доверенные вычисления избавляют от необходимости доверять людям

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

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

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

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

***

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

Литература

1. J. Campbell, The Masks of God. Vol. 4: Creative Mythology, Penguin Books, 1991.
2. C. Catlett et. al., A Scientific Re search and Development Approach to Cyber Security. Report submitted to the US Dept. of Energy, Dec. 2008, p. 2; www.er.doe.gov/ascr/ProgramDocuments/Docs/CyberSecurityScienceDec 2008.pdf.
3. K. Thompson, Reflections on Trusting Trust. Comm. ACM, vol. 27, no. 8, 1984.
4. M. Bishop, D.A. Frincke, Who Owns Your Computer? IEEE Security & Privacy, vol. 4, no. 2, 2006.
5. Sun Tsu, The Art of War, Delta Publishing, 1989.
6. R. Naraine, 90-Day Report Card: Windows Vista Fared Better than Competitors. ZDnet, 22 Mar. 2007; http://blogs.zdnet.com/security/?p=135.
7. T. Wu, A Real-World Analysis of Kerberos Password Security. Proc. 1999 Symp. Network and Distributed System Security, Internet Soc., 1999.

Эдвард Тэлбот (ebtalbo@sandia.gov) – руководитель отдела компьютерной и сетевой безопасности Sandia National Laboratories; Дебора Фринке (deborah.frincke@pnl.gov) – научный руководитель по вопросам кибербезопасности лаборатории Pacific Northwest National Laboratory; Мэтт Бишоп (bishop@cs.ucdavis.edu) – профессор информатики Университета Калифорнии.