Справочник от Автор24
Поделись лекцией за скидку на Автор24

Моделирование опасностей ПО. Правила создания и именования объектов

  • 👀 524 просмотра
  • 📌 508 загрузок
Выбери формат для чтения
Загружаем конспект в формате pdf
Это займет всего пару минут! А пока ты можешь прочитать работу в формате Word 👇
Конспект лекции по дисциплине «Моделирование опасностей ПО. Правила создания и именования объектов» pdf
Моделирование опасностей ПО Тема вашего задания • Моделирование опасностей разрабатываемых программных решений (ПО) Вопрос 1 Суть задания Необходимость моделирования Моделирование опасностей как средство проектирования защищенных приложений • Моделирование позволяет лучше разобраться в приложении. Тщательно, шаг за шагом изучая приложение, вы волейневолей в деталях изучите, как оно работает • Моделирование помогает находить ошибки в программе. Примерно половина всех ошибок «всплывает» в процессе анализа опасностей, а вторая половина — во время тестирования и анализа кода • Обнаруживаются сложные ошибки проектирования, которые практически не удается выявить другими способами. • Модели опасностей помогают новым сотрудникам детально разобраться в приложении. • Модели опасностей помогают новым сотрудникам детально разобраться в приложении. • Модели опасностей полезны и тестировщикам: проверка ПО на основе моде ли опасностей поможет разработать новые средства тестирования. процесс моделирования опасностей 1. создание группы моделирования опасностей; 2. разложение приложения на составляющие; 3. определение опасностей, грозящих системе; 4. упорядочение опасностей в порядке убывания степени их серьезности; 5. определение методов реагирования на опасности; 6. выбор методов борьбы с опасностями; 7. отбор технологий для выбранных методов борьбы с опасностями. Стадии процесса моделирования опасностей Создание группы моделирования опасностей проводится предварительный анализ опасностей. • Группу должен возглавить самый компетентный в вопросах безопасности человек (умеет находить в приложении или его проекте возможные направления атаки системы) • Желательно присутствие по крайней мере по одному представителю от каждой подгруппы, в том числе от проектировщиков, программистов, тестировщиков и технических писателей. Чем разнороднее группа, тем шире охват • задача не в решении проблем, а в выявлении компонентов системы и путей их взаимодействия, а конечный итог мероприятия — обнаружение как можно большего числа опасностей, грозящих системе Вопрос 2 Разложение программы на составляющие Диаграммы потоков данных (data flow diagrams, DFD) • DFD – часть UML • приложение или систему можно разбить на подсистемы, а те, в свою очередь, — на более мелкие подсистемы следующего уровня. Семантика блоков Контекстная диаграмма (DFD –диаграмма уровня 0) • определяют границы или область действия анализируемой системы, • определяют границы между доверенными и недоверенными компонентами. • границы приложений определяют на основе высокоуровневого представления контекстов. Если не определить область действия приложения, можно потерят массу времени на анализ тех опасностей, что находятся за пределами «компетенции» приложения и не имеют к нему никакого отношения. • диаграмма контекста содержит один-единственный процесс и обычно не содержит хранилищ данных: пользователь и система — и никаких деталей. • На следующих стадиях вы перемещаетесь на все более низкие уровни — к диаграммам уровня 0, уровня 1, уровня 2 и т. Семейство DFD-диаграмм АС Основной принцип анализа на основе DFDдиаграмм — спуск по иерархической лестнице от диаграммы контекста к низкоуровневым DFD-диаграммам Принципы построения контекстной диаграммы • игнорируйте внутреннее устройство приложения. На этом этапе вас не должно интересовать, как оно работает, — вы определяете область действия, а не подробности работы приложения; • выясните, на какие события и запросы должна реагировать система. • определите, какой ответ генерирует процесс. • выявите взаимоотношения источников данных с запросами и откликами. Учтите, что источники данных делятся на постоянные (файлы, реестр, базы данных и т. п.) и временные (данные в кэше); • определите получателей всех откликов Контекстная диаграмма для Web-приложения расчета зарплаты DFD-диаграмма уровня 1 Правила создания и именования объектов • каждому процессу соответствует как минимум один входящий и один исходящий поток данных; • все потоки данных начинаются и заканчиваются на процессах; • хранилища данных соединяются с процессами через потоки данных; • хранилища данных никогда не соединяются друг с другом напрямую — только через процессы; • названия процессов состоят из глаголов и существительных или фраз на основе ; • названия потоков данных — существительные или фразы на их основе; • названия внешних субъектов — существительные ; • названия хранилищ данных — существительные Глубина DFD-моделирования • для моделирования опасностей достаточно спуститься на два, три или четыре уровня • достаточно дойти до • уровня, позволяющего выявить опасности Высокоуровневое физическое представление приложения расчета зарплаты в составе АС Определение опасностей, грозящих системе. Методика STRIDE Исследование компонентов АС на опасность • может ли неавторизованный пользователь просматривать конфиденциальные данные, пересылаемые по сети; • может ли посторонний пользователь изменить записи базы данных; • может ли ктото помешать работе правомочных пользователей с приложением; • может ли ктото воспользоваться недоставками функции или компонента для получения полномочий администратора? STRIDE Подмена сетевых объектов (Spoofing identity) взломщик выдает себя за другого пользователя или подменяет настоящий сервер подложным. Модификация данных (Tampering with data) Злонамеренную порчу данных. Отказ от авторства (Repudiation) Контрагент отказывается от совершенного им действия (или бездействия), пользуясь тем, что у другой стороны нет никакого способа доказать обратное. Разглашение информации (Information disclosure) Раскрытие информации лицам, доступ к которой им запрещен, а также способность злоумышленника считывать данные при передаче между компьютерами. Отказ в обслуживании (Denial of service) Взломщик пытается лишить доступа к сервису правомочных пользователей. Повышение привилегий (Elevation of privilege) Непривилегированный пользователь получает привилегированный доступ, позволяющий ему «взломать» или даже уничтожить систему. К повышению привилегий относятся и случаи, когда злоумышленник удачно проникает через защитные средства системы и становится частью защищенной и доверенной подсистемы. Особенности анализа опасностей • При анализе уязвимых мест важно учитывать как их причины, так и последствия. • Некоторые типы опасностей взаимосвязаны Дерево опасностей деревья неисправностей (fault trees). • • • • • Опасность, грозящая системе – вероятность успешной атаки с нежелательными последствиями для системы. Брешь — это слабое место в системе (ошибка в программе или недостаток проекта) Атака выполняется, когда у злоумышленника есть мотив (причина для атаки) и возможность воспользоваться брешью для получения доступа к ценному ресурсу (asset). Ценный ресурс в терминах безопасности также объектом под угрозой (threat target). Защиту можно анализировать в терминах опасностей (реализуемых взломщиками в виде атак), брешей и ценных информационных ресурсов по аналогии с пожаром. • Схема анализа на основе деревьев (FTA) такова: 1. выявляем, какие элементы приложения могут стать целью атак, 2. выясняем возможное слабое место каждого элемента (именно через них при определенных условиях удастся взломать систему). • • Дерево опасностей описывает процесс принятия решения злоумышленником при взломе компонентов системы. Получив в результате декомпозиции приложения список компонентов, необходимо определить опасности, грозящие каждому из них. Далее с помощью деревьев опасностей следует установить, как проявляет себя конкретная опасность Пример ДО Опасность нужно связывать непосредственно с определенным в процессе декомпозиции объектом!!! Дополнение ДО • для отображения менее вероятных мест атаки -- пунктирные линии, для более вероятных — сплошные • под узлами маловероятных событий в кружочке помещают объяснение, почему опасность невелика • процессе моделирования не следует описывать способы предотвращения опасностей. (теряется динамика) Дополненное ДО Особенности моделирования опасностей Название: Должно быть информативным, но не длинным. Опасность должна быть легко понятна из названия Объект под угрозой : Часть приложения, подверженная атаке. Тип или типы опасности : Тип опасности по модели STRIDE. Часто опасность подпадает под несколько категорий STRIDE Риск : Любой метод расчета риска, но не меняйте метод в процессе анализа Дерево атаки : Как хакеробнаружит место взлома. Не усложняйте деревья Методы уменьшения опасности (при необходимости) : Методы устранения или ослабления опасности. Во время моделирования опасностей не нужно искать решений проблем. Отметить степень сложности устранения опасности. Статус методов устранения опасности : Уровень устранения опасности. Значения: «Да», «Нет», «Частично», «Требует дополнительного изучения» Номер ошибки (при необходимости) : нумерация, чтобы не запутаться При моделировании опасностей описывайте все интерфейсы системы, независимо от того, задокументированы ли они Оценка риска 1.Простой способ оценки риска = <Потенциальный ущерб> * <Вероятность возникновения> Критичность и вероятность оценивают по шкале от 1 до 10: 2.DREAD-методика оценки риска = среднее значение по пяти показателям После вычисления риска всех опасностей отсортируйте их в порядке убывания оценки, начиная с наибольшей Показатели DREAD • Потенциальный ущерб (Damage potential) — мера реального ущерба от успешной атаки. Наивысшая степень (10) опасности означает практически беспрепятственный взлом средств защиты и выполнение практически любых операций. Повышению привилегий обычно присваивают оценку 10. В других ситуациях оценка зависит от ценности защищаемых данных.. Показатели DREAD (продолжение) • Воспроизводимость (Reproducibility) — мера возможности реализации опасности. Некоторые бреши доступны постоянно (оценка — 10), другие —только в зависимости от ситуации, и их доступность непредсказуема, то есть нельзя наверняка знать, насколько успешной окажется атака. Бреши в устанавливаемых по умолчанию функциях характеризуются высокой воспроизводимостью. Такой показатель — радость для хакеров. Показатели DREAD (продолжение) • Подверженность взлому (Exploitability) — мера усилий и квалификации, необходимых для атаки. Так, если ее может реализовать неопытный программист на домашнем компьютере, ставим большую жирную десятку (10). Если же для ее проведения надо потратить 100 000 000 долларов, оценка опасности —1. И еще: атака, для которой можно написать алгоритм [а значит, распространить в виде сценария среди вандалов любителей (script kiddies)], также оценивается в 10 баллов. Следует также учитывать необходимый для атаки уровень аутентификации и авторизации в системе. Например, если это доступно любому удаленному анонимному пользователю, подобная опасность оценивается 10 баллами. А вот атака, доступная только доверенному локальному пользователю, менее опасна. Показатели DREAD (продолжение) • Круг пользователей, попадающих под удар (Affected users) — доля пользователей, работа которых нарушается изза успешной атаки. Оценка выполняется на основе процентной доли: 100% всех пользователей соответствует оценка10, а 10% — 1 балл. Иногда опасность становится реальной только в системе, сконфигурированной особым образом. Опять же, оценивайте влияние опасности максимально удобным способом. Чрезвычайно важно проводить границу между сервером и клиентским компьютером: от ущерба, нанесенного серверу, пострадает больше клиентов и, возможно, другие сети. В этом случае балл значительно выше, чем оценка атаки только на клиентские компьютеры. Также не следует забывать о размерах рынка и абсолютном, а не только процентном, количестве пользователей. Один процент от 100 млн. пользователей — это все равно много. Показатели DREAD (продолжение) • Вероятность обнаружения (Discoverability) — самая сложная для определения оценка. Откровенно говоря, я полагаю, что любая опасность поддается реализации, поэтому выставляю всем по 10 баллов, а при ранжировании опасностей учитываю другие показатели. Пример оценки по DREAD Опасность №1: Просмотр конфиденциальных данных о зарплате при их передаче через сеть 8 10 7 10 10 Потенциальный ущерб: просмотр личных данных о зарплате других пользователей — это серьезно Воспроизводимость: воспроизводима на 100% Подверженность взлому: злоумышленник должен находиться в одной с сервером или клиентом подсети или взломать маршрутизатор Пользователи под ударом: все, в том числе и генеральный директор Возможность обнаружения: просто предположим, что атака обнаруживается моментально RiskDREAD: (8 + 10 + 7 + 10 + 10) / 5 = 9 Споcоб анализа опасностей компании ISS • как реализуется атака: при локальном или удаленном доступе? Может ли злоумышленник атаковать, не имея локального доступа? Очевидно, что «удаленные» атаки опаснее «локальных»; • каковы последствия реализации опасности? Если это повышение привилегий, то до какой степени? Существует ли проблема разглашения информации? Влечет ли разглашение информации захват привилегий; • нужны ли какиелибо дополнительные действия для успеха атаки? Так, атака, успешная всегда и на любом сервере, опаснее той, для которой обязательно наличие административных полномочий. DFD + FTA + STRIDE + DREAD 1. Декомпозиция системы (DFD) для определения объектов под угрозой, 2. По методике STRIDE выявление опасности, грозящие каждому компоненту для каждого компонента системы надо продумать ответы на следующие вопросы: a) b) c) d) e) f) поддается ли компонент подмене; возможно ли модифицировать компонент; удастся ли злоумышленнику уйти ненаказанным, если он откажется от своих действий; возможен ли просмотр компонента; удастся ли взломщику блокировать доступ к процессу или потоку данных; может ли злоумышленник повысить свои полномочия, успешно атаковав процесс? 3. Деревья опасностей (FT) для составления сценариев того, каким образом опасность превратится в уязвимое место 4. Оценка риска по методике DREAD или любой др. Связь элементов DFD-диаграмм и категорий опасностей в модели STRIDE Особенности DREAD-оценки • DREAD-оценка опасности является результатом прохождения дерева именно по пути наименьшего сопротивления. • Это не значит, что взломщики не пойдут по другим маршрутам — пойдут, не сомневайтесь, — но первым скорее всего выберут самый легкий путь. Методика моделирования опасностей Этап 1. Выполните декомпозицию приложения на объекты под угрозой по одному из методов анализа, например с помощью DFD-диаграмм. В DFD-диаграммах объектами под угрозой считаются все источники данных, процессы, потоки данных, внешние субъекты и действующие лица. Этап 2. По методике STRIDE определите опасности, возможные для каждого объекта под угрозой. Они становятся вершинами деревьев опасностей; для каждого объекта под угрозой строится одно дерево. Этап 3. В зависимости от ситуации постройте одно или более деревьев опасностей для каждого объекта под угрозой. Этап 4. Оцените риск безопасности для каждого дерева опасностей по методике DREAD или аналогичному методу ранжирования опасностей. Этап 5. Отсортируйте опасности в порядке убывания риска. Реакция на опасность • ничего не предпринимать; • предупредить пользователей; • устранить причину опасности вместе с частью приложения; • устранить причины, изза которых система подвергается опасности. Отбор методов для предотвращения опасности 1. определяют подходящие методы, 2. определяют подходящие технологии. • Методы определяются, когда уже четко ясно, технологии какого типа годятся для предотвращения опасности Методы защиты Аутентификация • базовая аутентификация; • аутентификация на основе хеша; • аутентификация на основе форм; • аутентификация Microsoft Passport; • стандартная аутентификация Windows; • аутентификация по протоколу NTLM (NT LAN Manager); • аутентификация по протоколу Kerberos v5; • аутентификация на основе сертификатов X.509; • протокол IPSec (Internet Protocol Security); • RADIUS. Авторизация • списки управления доступом (Access control lists, AСL); • привилегии; • IP-ограничения; • серверные разрешения. Технологии защиты от несанкционированного доступа и обеспечения конфиденциальности • • • • SSL/TLS; IPSec; DCOM и RPC; EFS. Шифрование, хеши, MAC-коды и цифровые подписи • Хеширование — это применение к данным криптографической функции, называемой хешфункцией, или функцией дайджеста. В результате получается небольшое по размеру (по отношению к объему исходных данных) значение, однозначно идентифицирующее данные • Получив данные с хешем, адресат может проверить, не изменялись ли данные, повторно вычислив хеш и сравнить его с полученным. Совпадение хешей свидетельствует о том, что данные не изменялись. • При создании MAC-кода хеш-функция применяется к объединению самого сообщения и некоторых секретных данных, известных только доверенным сторонам Аудит • Цель аудита, иногда его называют журналированием (logging), состоит в сборе информации об успешных и неудачных попытках доступа к объектам, использования привилегий и других важных с точки зрения безопасности действий, а также регистрации этой информации для дальнейшего анализа в защищенном журнале. • Все файлы журналов необходимо защитить от атак. При моделировании следует учесть опасность, связанную с вероятностью и последствиями чтения, изменения или удаления файлов журнала, а также с невозможностью приложения добавлять записи в файл журнала из-за переполнения диска. • Фильтрация, управление входящими запросами и качество обслуживания Фильтрация (filtering) — это проверка получаемых данных и принятие решения об обработке или игнорировании пакета. Так работают фильтрующие пакет брандмауэры, которые позволяют справиться с множеством атак типа «отказ в обслуживании», реализованных на IP-уровне. • Ограничение числа входящих запросов (throttling), позволяет ограничить количество запросов от анонимных пользователей, разрешив больше запросов с аутентификацией.. Важно ограничить число анонимных подключений. • Качество обслуживания (quality of service) поддерживается набором компонентов, разрешающих приоритетную обработку некоторых типов трафика. Итог выполнения заданий • Итогом выполнения задания является список опасностей, ранжированный по критичности (значению риска), с указанием методов и средств, которые могут быть применены нейтрализации каждой найденной опасности
«Моделирование опасностей ПО. Правила создания и именования объектов» 👇
Готовые курсовые работы и рефераты
Купить от 250 ₽
Решение задач от ИИ за 2 минуты
Решить задачу
Помощь с рефератом от нейросети
Написать ИИ

Тебе могут подойти лекции

Смотреть все 81 лекция
Все самое важное и интересное в Telegram

Все сервисы Справочника в твоем телефоне! Просто напиши Боту, что ты ищешь и он быстро найдет нужную статью, лекцию или пособие для тебя!

Перейти в Telegram Bot