Лекция 19-20. Модель противостояния угроз и средств защиты Уязвимость возникает по двум причинам: 1. Существуют ошибки в средствах защиты. 2. Незнание об угрозе или предположение о том, что данной угрозы не будет в системе. Нарушитель может использовать угрозы, которые, при проектировании средств защиты не учитывались. То есть нарушитель должен найти ошибки в обоснованиях угроз, от которых защищают средства защиты. Противостояние угроз и средств защиты Непосредственные ошибки в реализации средства защиты являются ошибками первого рода, а неправильные утверждения о функциях средств защиты ошибками второго рода. Как обеспечить и как оценивать безопасность? Оценивать безопасность можно по количеству уязвимостей. Борьба с ошибками в средствах защиты: 1. Уменьшение объема кода средств защиты. 2. Усиление тестирования. 3. Сертификация. Для сокращения уязвимостей ПО необходимо сокращать функциональные возможности ПО, контролировать их с помощью средств защиты или делать так, чтобы на них нельзя было воздействовать. Таким образом, уязвимость – есть ошибка, приводящая к нарушению функционального баланса между средствами защиты и другим программным обеспечением. Оценка безопасности системы: 1. Проверка известных уязвимостей; 2. Поиск новых уязвимостей. Обеспечение безопасности системы: 1. Контроль и своевременное исправление ошибок. 2. Минимизация объема кода средств защиты. 3. Контроль за тем, чтобы не было программного обеспечения, которое не контролировалось бы средствами защиты; 4. Уменьшение привилегий программ. Предусловия – логический предикат, который истинен до выполнения процедуры. Постусловия – логический предикат, который истинен после выполнения процедуры. Для доказательства корректности работы программ строятся формальные логические выводы на основе предусловий и постусловий. Пример уязвимости: уязвимость в драйверах. Плюсы и минусы экспериментального подхода Практически драйвер может прочитать файл, который пользователь прочитать не может. При проектировании Windows эти угрозы считались несущественными, т.к. в компании Microsoft считали, что разрабатывать драйвера будут либо сотрудники, Microsoft либо производители устройств. В драйвере может оказаться ошибка, которая позволит нарушителю заменить код драйвера, или выполнить произвольный. Решение: 1. Запрет модификации компонентов. Это возможно только до некоторого уровня, т.к. драйвера необходимо устанавливать, или обновлять. 2. Верификация того факта, что драйвер не несет в себе вредоносных функций. На практике эту процедуру часто заменяют на проверку цифровой подписи. Лучше не выдвигать предположений о корректной работе драйвера и делать драйвера частью средств защиты. При включении драйвера в средства защиты ошибки первого рода превращаются в ошибки второго рода. Корректность работы средств защиты зависит от выбранной доверенной среды. К уязвимостям в средствах защиты может привести любая ошибка. Данный подход представлен на следующем рисунке. Экспериментальный подход Следовательно, во избежание ошибок необходимо: 1. минимизировать средства защиты; 2. перенести по максимуму функциональность из драйвера в приложение В этом случае предыдущий рисунок изменится следующим образом: Модификация экспериментального подхода Достоинства и недостатки экспериментального подхода: Как было указано выше, на практике безопасность системы можно оценивать по наличию уязвимостей, т.к. это проще. То есть чем больше уязвимостей, тем менее система безопасна. Можно проверять наличие существующих уязвимостей, так как поиск новых уязвимостей является дорогостоящим. Подход, основанный на оценке уязвимостей, с точки зрения практики является эффективным, т.к. позволяет оценивать безопасность здесь и сейчас. Однако необходимо понимать, что свойства продукта при этом не исследуются, вместо этого проверяется наличие уязвимостей. Кроме того, так как мы не знаем всех уязвимостей, существование некоторых уязвимостей не может быть обнаружено, следовательно, оценка безопасности продукта в данном случае является неполной. Таким образом, экспериментальный подход хорошо работает, только если существует сведения об актуальных уязвимостях. При этом оценка безопасности должна быть постоянной, в отличие от теоретических моделей. Наличие или отсутствие уязвимостей ничего не говорит о функциональных возможностях продукта. В этом подходе распространяется информация об уязвимостях, следовательно, возможно использование этой информации для деструктивных действий. При этом непонятно, какому стандарту удовлетворяет продукт, какая модель в нем заложена. Контрольные вопросы 1. В чем заключается экспериментальный подход к определению безопасности информационных систем? 2. Каковы преимущества и недостатки экспериментального подхода? 3. Каковы причины возникновения уязвимостей? 4. Что такое атака? 5. Что такое эксплойт?
