В комментариях к моей предыдущей статье Амарао очень хорошо спросил меня вопрос .
Он спросил, как именно, по каким правилам мы ищем уязвимости в ПО.
Позвольте мне процитировать часть этого вопроса:
По каким алгоритмам, по каким правилам? Или это все по прихоти: «Я знаю, что такое мим!»? При этом метод где-то ничего точно не описывает - я думал, где-то нет.с этим вопросом Амарао , намеренно или невольно обращает внимание на проблему объективности при оценке уязвимости программного обеспечения, насколько эта оценка зависит или не зависит от проводящего ее эксперта.
Вопрос очень важный, а потому часто возникает как среди специалистов по безопасности, так и среди наших клиентов.
Действительно, если мы не в состоянии объективно оценить безопасность предлагаемой нам продукции, то как мы сможем выбрать ту, которая максимально соответствует нашим потребностям? Все производители, естественно, будут клясться, что их продукт — самый безопасный из когда-либо созданных.
Более того, каждый из них наверняка в это поверит, и поверит не без оснований.
Кажется, что сторонняя оценка программного обеспечения, такая как сертификация, могла бы решить эту проблему.
Но если нет объективных средств анализа, то как можно проверить качество самой оценки? Ведь оценка программного продукта в данном случае является продуктом или услугой сама по себе.
Хотя эти вопросы обсуждаются довольно часто, однозначного ответа на них я не увидел.
Но за время работы в этой области у меня сложились определенные представления о возможностях современной техники.
В этой статье я хочу проиллюстрировать свою следующую мысль: сегодня не существует алгоритм поиск уязвимостей, которые гарантировали бы цель Оценка безопасности.
Поэтому доверие к продукту может быть основано только на репутации экспертов, оценивших его, и на опыте его эксплуатации (фактически на репутации взломщиков, пытавшихся обойти защиту).
Все существующие методы поиска уязвимостей можно разделить на две категории: формальные и экспертные.
Формальные методы поиска уязвимостей программного обеспечения очень тесно связаны с формальными методами разработки.
Они основаны на использовании языков с четко определенным значением для спецификации проектируемого продукта; математические методы проверки правильности полученного проекта; автоматизированное создание программного кода.
В ходе проверки корректности также оцениваются возможные уязвимости.
Экспертные методы, как следует из названия, основаны на знаниях и опыте специалистов, проводящих оценку.
Несмотря на то, что по определению эти методы вряд ли можно назвать полностью объективными, начну с них.
Ээкспертные методы Экспертные методы основаны на том, что информационные системы создаются по более или менее известным шаблонам.
Существуют шаблоны архитектуры, шаблоны проектирования, шаблоны кода.
Разработчики используют известные средства и методы защиты.
Программы написаны на широко известных языках программирования, работают под управлением распространенных операционных систем, используют доступные библиотеки и имеют доступ к доступным сервисам.
И использование каждого из этих шаблонов открывает возможность появления тех или иных уязвимостей.
Так, например, если программа написана на C или C++, в ней можно попытаться найти «эксплуатируемое» переполнение буфера.
Если язык запросов программы довольно сложен, он может быть уязвим для злоупотреблений API. Если программа использует пароль для аутентификации пользователя, есть шанс его угадать.
Программы, работающие с СУБД, часто уязвимы для SQL-инъекций.
Этот список, как вы понимаете, огромен.
Более сложная система разлагается на составные части.
Далее анализируются эти части и их взаимодействие.
Итак, в системе, состоящей из серверной и клиентской части, необходимо проанализировать сервер, клиент и протокол взаимодействия между ними.
В этом случае может оказаться полезным также разложить отдельные части на составляющие.
Например, серверная часть часто состоит из СУБД и сервера приложений.
В свою очередь, сервер приложений может быть реализован как несколько процессов в операционной системе; каждый процесс использует определенные библиотеки.
Собственно, методика сводится к нахождению некоторого представления программы или системы в виде взаимодействующих частей.
Эта точка зрения должна позволить нам проанализировать, основываясь на имеющейся у нас исторической информации, уязвимость каждой части и уязвимости, связанные с их взаимодействием.
Хорошим примером экспертного подхода является метод, разработанный и используемый Microsoft. Метод описан, в частности, в книге «Моделирование угроз» [ 1 ].
Для анализа архитектуры программы используются диаграммы информационных потоков, а для представления полученных результатов — деревья атак.
Таким образом, экспертные методы основаны на умении специалиста грамотно декомпозировать программу и на его знании уязвимостей различных типов программ и протоколов.
Формальные методы По моему опыту, к «использованию математики» иногда относятся с благоговением, почти как к магическому действию.
Именно математические, формальные методы в понимании многих являются кандидатами на звание «серебряной пули», а результаты, полученные с их использованием, воспринимаются недостаточно критично.
Конечно, формальные методы создают более качественное программное обеспечение.
Они уже нашли свое применение в сферах, где к программам предъявляются повышенные требования к надежности и/или безопасности.
Постепенно области их использования расширяются; возможно, те, кто читает эту статью, уже используют хотя бы элементы таких методов или будут использовать их в будущем.
Думаю, что со временем использование формальных средств позволит не только улучшить качество получаемого продукта, но и снизить затраты на его разработку и поддержку.
* .
С другой стороны, хотя формальные методы могут дать отличные результаты, необходимо понимать их ограничения.
Любой, кто занимался построением и исследованием математических моделей, скажет вам, что любая модель может дать не больше того, что в нее заложено изначально.
Давайте возьмем пример очень простой модели очень простой программы, реализующей очень простой протокол.
Простой пример
Программа после запуска и инициализации должна дождаться установления соединения пользователем.После того, как соединение установлено, программа должна получить от пользователя его имя и пароль.
Если они окажутся верными, программа может приступить к передаче пользователю некоторой информации, документа.
После завершения передачи программа должна закрыть соединение и перейти к ожиданию нового соединения.
Мы хотим быть уверены, что с помощью этой программы незарегистрированный пользователь не сможет получить доступ к информации.
Один из возможных способов сделать это — построить модель автомата и изучить ее.
Принципиальная схема машины, имитирующей эту программу, показана на следующем рисунке.
В данной модели возможны только два маршрута: I→II→III→I и I→II→I.
Рассмотрев все возможные маршруты, приходим к выводу, что попасть в состояние, в котором документ читается, можно только успешно пройдя аутентификацию.
Полученный вывод подтверждает правильность нашего проекта.
Конечно, для нашей простой системы это было очевидно; в более сложной ситуации мы могли бы найти «неправильные» пути.
Если бы мы могли найти маршруты, которые переводят систему в состояние чтения документа без аутентификации, это означало бы, что мы нашли уязвимость.
Более того, поскольку мы будем знать, какие запросы необходимо сделать в каждом состоянии, чтобы осуществить соответствующий переход, мы сразу же узнаем метод, с помощью которого можно атаковать систему.
Казалось бы, это алгоритм анализа уязвимостей.
Мы создали модель, изучили ее; На выходе были либо методы атаки, либо вывод о безопасности системы.
Но учтите, что каждая модель может помочь нам найти уязвимости только определенных типов, в данном случае это ошибки в последовательности сообщений, которыми обмениваются пользователь и программа.
И мы строим ту или иную модель, потому что ожидаем найти уязвимости определенного типа.
Делая утверждение о безопасности программы на основе изучения математической модели, мы опираемся на ряд предположений о свойствах моделируемой программы и среды, в которой она работает.
Модельные предположения
Давайте обсудим некоторые предположения, которые мы сделали при построении нашей простой модели.Возможно, наше наиболее очевидное предположение заключается в том, что пользователь, предоставивший правильный пароль, является зарегистрированным пользователем.
Модель никоим образом не рассматривает проблемы перехвата, подбора или кражи пароля пользователя.
Для оценки программы с этой точки зрения потребуются дополнительные исследования.
Есть и менее очевидные предположения.
Например, пользователь, получающий документ, будет тем же пользователем, который ввел имя пользователя и пароль.
Это исключает из рассмотрения все атаки, связанные с перехватом сеанса.
Как мы видели, даже при рассмотрении очень простой программы мы вынуждены полагаться на множество предположений.
Для более сложных систем это еще более верно.
Каждый раз, когда мы делаем вывод о безопасности того или иного программного продукта или системы, мы опираемся на ряд предположений об ограниченности возможностей злоумышленника.
Некоторые предположения можно проверить.
Например, в некоторых случаях мы можем утверждать, что сеанс не будет перехвачен.
Это выглядит вполне правдоподобно, если пользователь работает с локальной клавиатурой и монитором, а операционная система поддерживает «доверенный путь».
Да, чуть не забыл, надо наверное еще предположить, что сессия автоматически завершается, если пользователь встает со стула.
Другие предположения не могут быть проверены.
Некоторые из них невозможно проверить, поскольку мы не знаем пределов физических возможностей злоумышленника.
Например, его способность перехватывать электромагнитное излучение компьютера.
Мы можем догадываться, какими средствами располагает злоумышленник, у нас даже могут быть основания быть уверенными в этом знании.
Но мы не можем быть полностью уверены.
Возможно, завтра ситуация существенно изменится.
Вполне возможно, что инструменты атаки уже находятся в относительно свободном доступе, но мы об этом пока не знаем.
Некоторые логические предположения также не могут быть проверены.
Примером такого предположения является безопасность алгоритма RSA. Насколько мне известно, строгих формальных доказательств его невзломаемости нет. Это означает, что завтра может появиться техника взлома, и все системы, основанные на использовании этого алгоритма, станут незащищенными.
Более того, мы не можем быть абсолютно уверены, что никто до сих пор не знает, как атаковать этот алгоритм.
Конечно, есть веские причины полагать, что RSA сейчас в безопасности, но задайте себе вопрос: если бы у вас был бизнес стоимостью в пару миллиардов долларов (что сделало бы его интересной целью), сделали бы вы его полностью зависимым от RSA? ? Интересно, что все эти предположения не связаны с тем, что мы мы что-то знаем - как решить ту или иную проблему - но с тем, что мы мы чего-то не знаем .
Каждый раз, когда нам нужно проверить то или иное наше утверждение, возникает вопрос: мы не можем решить эту задачу, и никто не знает, как это сделать, или метод решения известен, но мы его не знаем? Тот, кто хоть немного помнит школьный курс математики, легко заметит, что все математические модели основаны на аксиомах – предположениях, которые невозможно доказать в рамках самой модели.
И разница между «хорошей» и «плохой» моделью может заключаться только в достоверности сделанных предположений.
Проверить утверждение типа «никто не может этого сделать» гораздо сложнее, чем проверить утверждение типа «мы можем это сделать».
В этом нам придется довериться экспертам.
И мы приходим к, казалось бы, парадоксальному выводу о субъективности формальных моделей в сфере безопасности, об их зависимости от опыта эксперта.
выводы Отсутствие уязвимостей невозможно продемонстрировать, в отличие от того, как можно продемонстрировать, например, функциональность программы или ее производительность.
Приходится доверять мнению эксперта.
Даже если конкретный эксперт не знает, как атаковать данную систему, это не означает, что она безопасна.
Даже если ни один эксперт этого не знает, мы все равно не можем быть полностью уверены в том, что таких методов не существует. В этом случае только эксперт – или экспертное сообщество – может определить, какие проверки необходимо провести, каких усилий достаточно приложить, чтобы найти уязвимости в анализируемой программе.
Он может сделать это, основываясь на своих знаниях методов атаки на такие системы.
А доверие к результатам проверки может быть основано только на репутации экспертов, ее проводивших.
И я хочу закончить в рамках логики всей статьи.
Могу ли я сказать, что завтра Большого Открытия не будет сделано, в результате чего все сказанное в этой статье окажется неверным? Нет, я не могу.
Уверен ли я, что это Большое Открытие еще никем не сделано? У меня есть основания полагать, что этого еще не произошло.
Но я не могу быть полностью уверен.
Примечание * Если вас интересуют формальные подходы в целом, без относительной безопасности, то вам может быть интересно прочитать книгу «Понимание формальных методов» [ 2 ].
Очередная книга «Компьютерная безопасность.
Искусство и наука» [ 3 ] содержит много информации о математических моделях информационной безопасности, включая отдельную главу, посвященную формальным методам анализа безопасности программного обеспечения.
Литература 1. Фрэнк Свидерски, Окно Снайдер «Моделирование угроз», Microsoft Press 2004, ISBN 978-0-7356-1991-3. 2. Жан Франсуа Монен, Михал Г.
Хичи (редактор) «Понимание формальных методов», Springer-Verlag 2003, ISBN 1-85233-247-6. 3. Мэтт Бишоп «Компьютерная безопасность.
Искусство и наука», Аддисон-Уэсли, 2003 г.
, ISBN 0-201-44099-7. Теги: #безопасность #сертификация #информационная безопасность
-
Картриджи Epson – Это Решение
19 Oct, 24 -
Видеоотчеты С Конференции Devconf 2014
19 Oct, 24 -
Что Такое Бизнес-Аналитика
19 Oct, 24
