Построение диаграмм

Обычно мы пользуемся системой диаграмм, заимствованной из методологии построения диаграмм потоков данных (Data Flow Diagram, DFD), добавляя к ней «границы доверия». Как оказалось, такие DFD-элементы как «процесс», «хранилище данных», «поток данных» и «внешний элемент» отлично работают в качестве средств извлечения информации и могут использоваться при проведении анализа. Описание этих элементов приведено в таблице 1. Кроме того, мы добавили элемент «границы доверия», изображаемый в виде пунктирной линии или прямоугольника, который показывает, что элементы, расположенные по разные стороны от этой границы, функционируют на разных уровнях привилегий. Первоначальное решение об использовании DFD было основано на двух факторах. Во-первых, стандарт DFD прост для понимания, и, во-вторых, он ориентирован именно на рассмотрение данных. Огромное количество атак тем или иным образом используют потоки данных, проходящие через систему, а значит, DFD позволяет рассматривать как раз самую важную сторону вопроса. Опыт 7-8 лет применения DFD-подхода к построению диаграмм показал его надежность и эффективность. Другие методологии, предлагаемые для заметы DFD-подхода, должны продемонстрировать заметные преимущества перед DFD, чтобы мы могли рассматривать их в качестве альтернативы.

Название	Внешний элемент	Процесс	Поток данных	Хранилище данных
Графическое изображение	круг	прямоугольник	стрелка	параллельные линии
Определение	Объекты, не находящиеся под нашим контролем	Программный код	Как информация передается между элементами	Стационарные данные
Примеры	Люди, другие системы, web-сайты	exe-файлы, сборки, COM-компоненты	Вызовы функций	Файлы, базы данных, регистрационные ключи

Таблица 1. DFD-элементы

Обычно DFD-диаграмма содержит от 10 до 150 элементов (не включая границ доверия и текстовых пояснений). Основную сложность в диаграмму вносят границы доверия и та степень детализации, которая необходима для описания процессов, происходящих при переходе объектов через эти границы. Для многих систем мы строим диаграммы по восходящему принципу, и тому есть две причины. Во-первых, в Microsoft часто организуют группы, состоящие из разработчиков, испытателей и руководителей проектов, которые занимаются только выделенным для этой группы вопросом или вопросами. Поэтому представляется естественным и логичным разделить работу по моделированию угроз между этими группами так, чтобы каждая команда составляла модель угроз для своей части проекта. Вторая причина состоит в том, что язык SDL требует наличия моделей угроз для «всех новых блоков и продукта в целом». Я коснулся этого вопроса для того, чтобы показать, как одна конкретная формулировка в каком-либо описании может привести к совершенно неожиданным последствиям.

Дата добавления: 2015-11-14