Читайте также:
|
Многие специалисты, имея свое представление о том, как должно выглядеть моделирование угроз (термин, имеющий, как я уже отметил в разделе 1.1, множество значений), воплотили эти представления в своих методологиях и дополнениях к существующим методам. Чаще всего такие дополнения создаются без учета и осознания того, какие затраты потребуются на их внедрение, каковы приносимые ими выгоды и издержки. Пример – внедрение методики оценки рисков DREAD [6]. Для некоторых систем эта методика работает, но при моделировании угроз с акцентом на программном обеспечении методика DREAD начинает вводить числовые переменные, не задавая их области определения, что приводит к опасности принять оценку рисков за алгоритмическую, в то время как она таковой не является. Тем не менее, SDL-моделирование угроз в Microsoft явно нуждается в методике управления рисками, и поэтому DREAD была внедрена.
Сложность
Многие специалисты, занимающиеся моделированием угроз, не проходили соответствующее обучение, а просто узнали о том, что нужно делать, от других. Я был очень удивлен, увидев однажды целый отдел компьютерной безопасности, все сотрудники которого хорошо разбирались в методиках моделирования угроз и владели профессиональной лексикой, при этом ни разу не посетив какой-либо семинар. В Microsoft существует множество курсов по безопасности, инструментов и методик, однако стоит отметить, что большинство инженеров посетили максимум 2 часа семинарских занятий за последние несколько лет.
Метод, приведенный в описании SDL, включает 9 этапов. Некоторые другие методы содержат до 11 этапов. Сложность этапов сильно различается и варьируется от «описать сценарии использования» до «определить типы угроз». И если первое задание большинство инженеров должно выполнить, то второе, скорее всего, окажется не под силу неэкспертам, да и среди экспертов вызовет существенные разногласия. Описания методологий изобилуют специальными терминами, что еще больше усложняет их понимание.
Разработчикам методологий следует внимательнее и бережнее относиться к запросам пользователей и тщательно оценивать каждый этап или элемент.
Жизненность
Моделирование угроз может показаться сильно оторванным от реальной разработки программного обеспечения. Складывается такое ощущение, что меткое выражение «YAGNI» (Вам это никогда не понадобиться, «You Ain’t Gonna Need It») было создано специально для этого вида деятельности. Использование ряда подходов позволило интегрировать моделирование угроз в процесс разработки программных продуктов (сюда относится, например, работа с угрозами как с ошибками в программном коде и представление мер борьбы с ними в виде функциональных особенностей системы). Разработчики отлично понимают, что такое ошибки и функциональные особенности, и компании знают, как с ними работать. Кроме того, мы призываем проводить дискуссии в отделах по безопасности, задавая простой вопрос «можно взглянуть на Вашу модель угроз?». Это побудит Вас и Ваших коллег разрабатывать действительно хорошие модели (В большинстве случаев подходы, подобные Microsoft SDL, применяемые к различным методологиям разработки, могут показаться оторванными от жизни. Однако это вообще свойственно области моделирования угроз).
Существует еще два аспекта, оба связанные с человеческим фактором, на которых я хотел бы остановиться отдельно. Первый – это представление людей в модели угроз, и второй – это проблемы проектирования, вызванные человеческим фактором, возникающие при разработке методов, процедур и инструментов моделирования систем безопасности.
Дата добавления: 2015-11-14; просмотров: 50 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Перечисление угроз | | | Люди как пользователи систем моделирования средств защиты |