Системы для анализа защищенности информационных систем. Kali Linux: виды проверок информационных систем


Продолжаем рассматривать недавние изменения в приказ ФСТЭК России №17. В этот раз – анализ уязвимостей ГИС.

Теперь анализ уязвимостей ГИС требуется проводить на 3 из 6 этапах жизненного цикла системы защиты ГИС: формирования требований, внедрения и аттестации.

1. На этапе анализа угроз безопасности информации ГИС, необходимо провести анализ возможных уязвимостей ИС, используя при этом БДУ ФСТЭК России, а также иные источники данных об уязвимостях в качестве исходных данных. В модель угроз нужно включить описание возможных уязвимостей ИС.

Основное отличие от других этапов кроется в слове “возможных”. Не фактических, а именно возможных. А при наличие хорошей фантазии, у нас будет возможно всё. На сколько я понимаю, тут нужна некая классификация всех возможных уязвимостей и исключение неподходящих типов уязвимостей по определенным причинам (отсутствие объекта воздействия, определенные структурные характеристики, неиспользуемые ИТ).

Проблема в том, что в БДУ ФСТЭК в разделе Уязвимости отсутствует подобная классификация уязвимостей. Кроме того, разделе Уязвимости приведены только фактические уязвимости ПО. А как же уязвимости ГИС в целом? Недостатки орг. мер?

На самом деле, перечень таких возможных уязвимостей скрывается в неструктурированном виде в тексте угроз БДУ ФСТЭК: “Данная угроза обусловлена уязвимостями некоторых системных (материнских) плат – наличием механизмов аппаратного сброса паролей, установленных в BIOS/UEFI” или “Данная угроза обусловлена слабостями механизмов фильтрации сетевого трафика и антивирусного контроля на уровне организации”.

2. На этапе внедрения системы защиты информации требуется провести уже фактический анализ уязвимостей.

“При анализе уязвимостей информационной системы проверяется отсутствие известных уязвимостей средств защиты информации, технических средств и программного обеспечения, в том числе с учетом информации, имеющейся у разработчиков и полученной из других общедоступных источников, правильность установки и настройки средств защиты информации, технических средств и программного обеспечения, а также корректность работы средств защиты информации при их взаимодействии с техническими средствами и программным обеспечением.

По результатам анализа уязвимостей должно быть подтверждено , что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках, или их использование (эксплуатация) нарушителем невозможно.”


Но хорошо, что уязвимости имеют такие поля как Производитель, Наименование ПО, Версия ПО. Составив заранее полный перечень ПО, можно сделать выборку нужных уязвимостей. Но что делать с результатами? Например, для Windows 8.1 – 247 уязвимостей в БДУ. Далее нужно в каждой пройти по ссылке на внешние источники и проверить что там предлагалось для устранения уязвимостей, проверить наличие установленных обновлений для данных уязвимостей.

Вручную - сложно. Хотелось бы, чтобы сканнеры уязвимостей могли работать с БДУ и делать всё за нас. Давайте посмотрим…

RedCheck от Алтекс-Софт: “RedCheck производит поиск уязвимостей по нашей базе ovaldb которая синхронизируется с БД угроз безопасности информации ФСТЭК России! Список уязвимостей Вы можете посмотреть на сайте базы данных https ://ovaldb .altx -soft .ru /Definitions .aspx ?refsource =FSTEC .”

Вроде ок. Жаль только последняя уязвимость по ссылке – от 2016 г. А в БДУ уже куча за 2017 г.

Ревизор Сети 3.0 от ЦБИ: “Ревизор Сети изначально осуществляет поиск включенных в БДУ ФСТЭК России (http://bdu.fstec.ru) уязвимостей, содержащихся в операционных системах Windows и функционирующих в них приложениях и средствах защиты информации, в том числе российской разработки. Помимо поиска уязвимостей из базы данных уязвимостей ФСТЭК России Сетевой сканер «Ревизор Сети» версии 3.0 осуществляет поиск уязвимостей, содержащихся в таких источниках, как cve.mitre.org, ovaldb.altx-soft.ru, microsoft.com и других источниках. ”

XSpider от Positive Technologies “Обязательно такая возможность будет. В июне в рамках пересертификации XSpider будет передана в испытательную лабораторию ФСТЭК сборка уже с таким функционалом ”.

Сканер-ВС от Эшелон “Сканер-ВС поддерживает поиск уязвимостей по БДУ ФСТЭК России”. Правда опыт показал, что текущая, сертифицированная версия – не поддерживает.

Итого, в перспективе возможно за нас всё будут делать сканеры, но в данный момент готового отчета, подтверждающего отсутствие уязвимостей из БДУ ФСТЭК я не обнаружил. Да и с актуальностью баз вопросы – надо будет внимательно проверять результаты и возможно последние уязвимости просматривать вручную.

Кроме того, не забываем, что в анализ уязвимостей входит ещё анализ настройки СЗИ, ПО и ТС и анализ корректности работы СЗИ.

3. На этапе аттестации требуется провести следующие испытания “анализ уязвимостей информационной системы, в том числе вызванных неправильной настройкой (конфигурированием) программного обеспечения и средств защиты информации” при этом в качестве исходных данных используются “результаты анализа уязвимостей информационной системы” . Это как вообще?

Просто повторяем то что делали на этапе внедрения? С учетом последних требований к разделению аттестаторов и внедренцев, видимо тут расчет на выборочный независимый дублирующий анализ.

IDENTIFICATION OF INFORMATION SYSTEMS VULNERABILITIES

Sergei Konovalenko

postgraduate of Krasnodar higher military school,

Russia, Krasnodar

Igor Korolev

doctor of Engineering, Professor, Professor of the department of protected information technologies, Krasnodar higher military school,

Russia, Krasnodar

АННОТАЦИЯ

Проведена оценка существующих средств анализа защищенности информационных систем, на основе которой построены модели выявления, идентификации и оценки образов уязвимостей информационных систем. Определены основные характеристики (элементы), присущие образам существующих уязвимостей информационных систем.

ABSTRACT

An assessment of existing tools for analyzing information systems security was performed. On the basis of the achieved results the models of detection, identification and evaluation of information systems vulnerabilities images were built. The main characteristics (elements) inherent to the images of the existing information systems vulnerabilities were defined.

Ключевые слова: выявление; информационная система; идентификация; оценка; описание образа; уязвимость.

Keywords: detection; information system; identification; evaluation; description of the image; vulnerability.

Любой информационной системе (далее по тексту – ИС) присущи определенные уязвимости, перечень которых является достаточно объемным и постоянно подлежит обновлению (расширению). Уязвимости ИС обусловлены недостатками (ошибками), возникающими в процессе «жизненного цикла» этой системы. В этом виду, возможность реализации угроз безопасности ИС напрямую зависит от действий злоумышленника по обнаружению и использованию присущих ей уязвимостей. С другой стороны, процесс выявления уязвимостей ИС, проводимый специалистом, является основополагающим в противодействии злоумышленнику на ранних стадиях реализации атак.

Целью данной статьи является построение обобщенных моделей выявления, идентификации и оценки образов уязвимостей ИС, а также определение характеристик (элементов), присущих образам существующих уязвимостей, что позволит специалисту более качественно систематизировать свою работу в области обеспечения безопасности контролируемой ИС.

Согласно ГОСТ Р 56545-2015, «уязвимость» – это недостаток (слабость) программного (программно-технического) средства или ИС в целом, который (которая) может быть использована для реализации угроз безопасности информации . «Информационная система» – это совокупность содержащейся в базах данных (далее по тексту – БД) информации и обеспечивающих ее обработку информационных технологий и технических средств .

Любую уязвимость ИС можно представить в виде образа, который включает в себя набор определенных характеристик (элементов, описывающих данную уязвимость), формируемых по определенным правилам.

Описание уязвимости ИС – это информация о выявленной (обнаруженной) уязвимости . Правила описания уязвимости ИС – это совокупность положений, регламентирующих структуру и содержание описания уязвимости .

Согласно образы уязвимостей подразделяются на образы известных уязвимостей, образы уязвимостей нулевого дня и образы впервые выявленных уязвимостей. Известная уязвимость – это уязвимость, опубликованная в общедоступных источниках с описанием соответствующих мер защиты информации, исправлений недостатков и соответствующих обновлений . Уязвимость нулевого дня – это уязвимость, которая становится известной до момента выпуска разработчиком компонента ИС соответствующих мер защиты информации, исправлений недостатков или соответствующих обновлений . Впервые выявленная уязвимость – это уязвимость, неопубликованная в общедоступных источниках .

Каждому типу образов уязвимостей ИС присущи как общие, так и специфические характеристики (элементы), которые можно свести в таблицу. Пример таблицы представлен ниже.

Таблица 1.

Элементы различных типов образов уязвимостей ИС

Характеристики образа уязвимости

Элемент, присущий образу известной уязвимости

Элемент, присущий образу уязвимости нулевого дня

Элемент, присущий образу впервые выявленной уязвимости

Место обнаружения (выявления) уязвимости в ИС.

Способ обнаружения (выявления) уязвимости.

Наименование уязвимости.

Прежде чем перейти к моделям выявления, идентификации и оценки образов уязвимостей, необходимо пояснить, что ИС состоит из уровней :

  • уровень прикладного программного обеспечения (далее по тексту – ПО), отвечающий за взаимодействие с пользователем;
  • уровень системы управления базами данных (далее по тексту – СУБД), отвечающий за хранение и обработку данных ИС;
  • уровень операционной системы (далее по тексту – ОС), отвечающий за обслуживание СУБД и прикладного ПО;
  • сетевой уровень, отвечающий за взаимодействие узлов ИС.

Каждому из уровней ИС соотносят различные типы (классы) уязвимостей. Для выявления уязвимостей необходимо разрабатывать модели выявления, идентификации и оценки уязвимости.

Основными источниками возникновения уязвимостей ИС являются :

Для выявления, идентификации и оценки уязвимостей ИС, а также формирования отчетов и устранения (нейтрализации) уязвимостей, используются средства анализа защищенности сети (далее по тексту – САЗ) (сканеры безопасности (далее по тексту – СБ)), которые можно разделить на два типа :

  • сетевые САЗ (СБ) (осуществляют удаленный анализ состояний контролируемых хостов на сетевом уровне);
  • САЗ (СБ) уровня ОС (осуществляют локальный анализ состояний контролируемых хостов, порой требуется установка специального агента на контролируемых хостах).

Актуальность применения САЗ (СБ) обусловлена тем, что специалист способен заблаговременно определить достаточно большой перечень типов (классов) уязвимостей, присущих контролируемой ИС, и предпринять необходимые меры (в отдельных случаях, попытаться предпринять) по их устранению или исключению (минимизации) возможности использования обнаруженных уязвимостей злоумышленником.

Для систематизации работы специалиста в области обеспечения безопасности, контролируемой ИС и на основе проведенного анализа строится обобщенная модель выявления образов уязвимостей ИС (рисунок 1).

Рисунок 1. Обобщенная модель выявления образов уязвимостей ИС

Процесс выявления уязвимостей ИС строится посредствам выполнения пассивных проверок (сканирование – scan) и активных проверок (зондирование – probe) наличия уязвимостей контролируемой ИС.

В процессе сканирования САЗ, отправляя соответствующие запросы в адрес контролируемой ИС (на порты контролируемого хоста), анализирует обратно возвращаемые баннеры (заголовки пакетов данных) и делает соответствующие выводы о типе ИС и наличии потенциальных (возможных) ее уязвимостей. Результат сканирования не всегда на сто процентов говорит о наличии возможных (типовых) уязвимостей ИС, так как текстовое содержание баннера могло быть специально модифицировано, либо известные уязвимости, присущие данной ИС, были устранены специалистом в процессе ее реализации (использования). Еще одним способом выполнения сканирующих действий являются активные зондирующие проверки, которые предоставляют возможность проанализировать возвращаемый цифровой слепок (fingerprint) фрагмента ПО контролируемой ИС (т. е. выполнить процесс сравнения полученного результата с цифровым слепком известной уязвимости данного типа ИС). Данный способ обеспечивает более надежную и точную процедуру выявления возможных (типовых) уязвимостей контролируемой ИС.

В процессе зондирования САЗ имитирует выполнение атаки на контролируемую ИС, используя образ возможной (типовой) уязвимости, полученной при сканировании. Результат процесса зондирования является самой точной и надежной информацией о наличии уязвимостей контролируемой ИС. Данный способ применяется не всегда, так как существует вероятность нарушения работоспособности (вывода из строя) контролируемой ИС. Решение на применение вышеуказанного способа принимает администратор сети в случаях не эффективного выполнения или необходимости подтверждения результатов сканирования и активных зондирующих проверок.

Результаты сканирования и зондирования поступают в БД уязвимостей, в которой хранятся образы уязвимостей контролируемой ИС. На основании процедуры сравнения образа обнаруженной уязвимости с образами уязвимостей контролируемой ИС САЗ формирует отчет об отсутствии или наличии совпадений в образах уязвимостей (обнаружение уязвимостей), который сохраняется в БД уязвимостей.

Детализирует обобщенную модель выявления образов уязвимостей обобщенная модель идентификации и оценки образов уязвимостей ИС (рисунок 2).

Рисунок 2. Обобщенная модель идентификации и оценки образов уязвимостей ИС

Процесс идентификации образа обнаруженной уязвимости ИС, который имеет специфические характеристики (элементы), осуществляется посредствам процедуры его сравнения с образами известных уязвимостей и уязвимостей нулевого дня, хранящихся в БД уязвимостей. Формализованное описание известных уязвимостей и уязвимостей нулевого дня оформляется в виде паспортов, которые содержат информацию о специфических характеристиках (элементах) конкретной уязвимости. Для точной идентификации образа обнаруженной уязвимости он должен содержать информацию о наименовании и версии ПО ИС, в которой обнаружена уязвимость, о идентификаторе, наименовании и классе обнаруженной уязвимости. На основании вышеуказанной информации САЗ соотносит образ обнаруженной уязвимости к одному из типов образов уязвимостей. Для качественного проведения оценки идентифицированный образ уязвимости, в свою очередь, должен содержать информацию об идентификаторе и типе недостатка ИС, при котором обнаружена уязвимость, о месте обнаружения уязвимости в ИС, о способе выявления уязвимости. Процесс оценки образа уязвимости оканчивается выработкой рекомендаций по устранению уязвимости или по исключению возможности ее использования. В случаях, если был обнаружен образ впервые выявленной уязвимости, то САЗ помещает информацию о нем в БД уязвимостей с формированием нового паспорта уязвимости нулевого дня. При выпуске разработчиком ИС мер защиты информации, необходимых обновлений и при исправлении недостатков, уязвимость нулевого дня переходит в статус известной уязвимости.

Поводя итоги данной статьи, отмечаем, что специалист по обеспечению безопасности ИС обязан постоянно проводить работу по выявления уязвимостей в системе, четко представлять и понимать процессы, протекающие в САЗ, следить за обновлением (расширением) БД уязвимостей, своевременно устранять недостатки в системе, устанавливать соответствующие меры защиты и обновления на контролируемую ИС.

Список литературы:

  1. Астахов А.С. Анализ защищенности корпоративных автоматизированных сетей // Информационный бюллетень Jet Info. – 2002. – № 7 (110). / – [Электронный ресурс]. – Режим доступа: URL: http://www.jetinfo.ru
  2. Горбатов В.С., Мещеряков А.А. Сравнительный анализ средств контроля защищенности вычислительной сети // Безопасность информационных технологий. – 2013. – № 1. / – [Электронный ресурс]. – Режим доступа: URL: http://www.bit.mephi.ru
  3. ГОСТ Р 56545-2015 «Защита информации. Уязвимости информационных систем. Правила описания уязвимостей». – М.: Стандартинформ, 2015.
  4. ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем». – М.: Стандартинформ, 2015.
  5. Лукацкий А.В. Как работает сканер безопасности? / – [Электронный ресурс]. – Режим доступа: http://www.citforum.ru/security/internet/scaner.shtml (Дата обращения: 14.09.2016).
  6. Лукацкий А.В. Обнаружение атак. – СПб. : Издательство «БВХ», 2001. – 624 с.
  7. Руководство пользователя программного комплекса «Средство анализа защищенности «Сканер-ВС». НПЭШ.00606-01. ЗАО «НПО «Эшелон», 2011.
  8. Сканер безопасности XSPider. Руководство администратора / – [Электронный ресурс]. – Режим доступа: http://www.ptsecurity.ru (Дата обращения: 15.09.2016).
  9. Сканер безопасности MaxPatrol. Система контроля защищенности / – [Электронный ресурс]. – Режим доступа: http://www.ptsecurity.ru (Дата обращения: 16.09.2016).
  10. Стивен Норткат, Джуди Новак. Обнаружение нарушений безопасности в сетях. 3-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – С. 265–280.

Киверина Н.Ш.

Кандидат технических наук, Евразийский национальный университет имени Л.Н.Гумилева

АНАЛИЗ УЯЗВИМОСТИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Аннотация

В статье описывается метод анализа уязвимостей любой информационной системы. Также представлены по категориям угрозы безопасности. С помощью данной методики составляется документ, содержащий описание информационной системы, ее компонент, всех потенциальных для системы угроз и мер, необходимых для их устранения.

Ключевые слова: угрозы безопасности, информационные системы, анализ.

Kiverina N.SH.

Candidate of Technical Sciences, Eurasian National University of L.N.Gumilev

ANALYSIS OF THE VULNERABILITY OF AN INFORMATION SYSTEM

Abstract

Describes a method of analysis of any information system vulnerabilities. Also represented are a security threat. Using this technique, a document containing a description of the information system, its components, all potential for threats and actions needed to address them.

Keywords: security threats, information systems, analysis.

Обеспечение защищенности информационной системы является одним из важнейших этапов ее разработки и поддержки. Очевидно, что информационная система, отданная в производство без каких-либо средств защиты от угроз, не несет никакой практической и материальной ценности. Например, система совершения и обработки торговых сделок, реализованная без использования алгоритмов шифрования, не может гарантировать целостность обрабатываемых данных. Естественно, такая система не должна и не будет использоваться в реальных торговых операциях. При проектировании любой новой информационной системы, а также при использовании уже реализованной системы стоит проблема гарантии ее защищенности от компрометации. Гарантия нужна не только для конечного пользователя, но и, например, для лица, выделяющего средства на разработку информационной системы. Анализ защищенности разрабатываемой системы рекомендуется проводить с помощью моделирования потенциальных угроз. В последнее время новые уязвимости появляются каждый день, поэтому важно уметь классифицировать угрозы и оценивать их по степени риска. Информационная безопасность определяется всеми аспектами, связанными с достижением и поддержанием конфиденциальности, целостности, доступности, неотказуемости, подотчетности, аутентичности и достоверности информации или средств ее обработки. Защита информации должна носить комплексный характер, однако, необходимо учитывать возможность возникновения угроз, специфичных для данной информационной системы. На этапе проектирования системы защиты информации важно не упустить существенных деталей и, в то же время, не переоценить некоторые из них. Необходимо знать о характере возможных опасностей, классифицировать угрозы и проводить меры по их устранению. Основной принцип обеспечения безопасности информационной системы лежит в анализе потенциальных угроз, проведении мер по их устранению и последующем анализе состояния безопасности системы. Моделирование угроз позволяет структурировать процесс обеспечения безопасности информационной системы и обозначить угрозы, которые способны нанести наибольший ущерб и которые необходимо устранить в первую очередь. Нельзя обеспечить безопасность информационной системы без должного понимания специфики и происхождения угроз. Обычно, уязвимости устраняются по мере их обнаружения, часто случайным образом. Используя этот подход, невозможно ответить на вопрос: «Достаточно ли безопасна информационная система?». Моделирование угроз не является единовременным процессом. Это итеративный подход, который начинается с ранних стадий разработки системы и продолжается на протяжении всего ее жизненного цикла. Необходимость итеративного подхода обусловлена двумя причинами. Во-первых, физически невозможно обнаружить и зафиксировать все потенциальные для системы угрозы за один раз. Во-вторых, разрабатываемое приложение (информационная система) непременно адаптируется под постоянно изменяющиеся пользовательские и функциональные требования. Поэтому моделирование угроз необходимо повторять на протяжении всего развития информационной системы. Специалисты по безопасности компании Microsoft предложили процесс моделирования угроз, состоящий из шести этапов : 1. Определение защищаемых ресурсов. 2. Обзор архитектуры. 3. Декомпозиция системы. 4. Определение угроз. 5. Документация угроз. 6. Приоритезация угроз. На первом этапе определяются все ресурсы, которые необходимо защищать. Это могут быть конфиденциальные данные, базы данных, веб-страницы и т.д. Далее проводится документация функций информационной системы, ее архитектуры, физической конфигурации и технологий, использованных для ее реализации. Возможен поиск уязвимостей в дизайне информационной системы. Определение используемых в реализации технологий поможет не упустить специфичных для них уязвимостей и в дальнейшем сконцентрироваться на их устранении. На этапе декомпозиции система разбивается на компоненты для создания профиля безопасности (который описывает реализацию аутентификации, авторизации, криптографии и других аспектов безопасности в системе). Проверяются основные вопросы безопасности, выделяются границы доверия, потоки данных и их входные точки. Система анализируется на исполнение следующих свойств: проверка пользовательских данных, аутентификация и авторизация, криптографическая защита передачи данных, управление исключениями, аудит и др. Профиль безопасности описывает реализацию аутентификации, авторизации, криптографии и других аспектов безопасности в системе. Далее определяются потенциальные угрозы для всех компонент системы. Компания Microsoft предлагает методику STRIDE для определения и категоризации угроз . Моделирование при помощи STRIDE поможет обеспечить исполнение в информационной системе всех свойств безопасности. STRIDE – аббревиатура от:  Spoofing Identity (подмена личности).  Tampering with Data (изменение данных).  Repudiation (отказ от совершенной операции).  Information Disclosure (разглашение сведений).  Denial of Service (отказ в обслуживании).  Elevation of Privilege (повышение прав доступа).

По этой методике определяются угрозы для каждого компонента информационной системы в зависимости от категории угрозы. Угрозы типа «Подмена личности» актуальны для систем, в которых реализуются разные уровни доступа пользователей. Пользователь не должен иметь возможность притвориться другим пользователем или прочитать атрибуты другого пользователя. Угрозы типа «Изменение данных» реализуют возможность пользователя повлиять на логику работы системы через доступные интерфейсы. Система должна тщательно проверять все исходящие от пользователя данные в процессе их использования и вплоть до момента их сохранения в системе. При недостаточном аудите транзакций в системе угрозы типа «Отказ от совершенной операции» реализуют возможность пользователя отказаться от выполненных им каких-либо действий в системе, что может повлиять на достоверность циркулирующей по системе информации. Например, пользователь может заявить «Я не перечислял денежные средства на этот счет». При недостаточном аудите операций невозможно проверить данное заявление. Угрозы типа «Разглашение сведений» реализуют возможность публикации конфиденциальных данных в системе. Возможно, в системе обнаружится утечка информации. Дизайнеры системы также должны учитывать тот факт, что на нее будут проводиться атаки типа DoS (отказ в обслуживании). Необходимо убедиться, что ресурсоемкие процессы будут недоступны неавторизованным пользователям. Такими процессами могут являться: чтение больших файлов, сложные вычисления, исполнение длинных запросов к базе данных и т.д. Если в системе различаются пользовательские и административные роли, то необходимо убедиться в невозможности повышения прав доступа. Все действия в системе должны проверяться по матрице доступа. На следующем этапе моделирования все определенные угрозы необходимо зафиксировать в представленном далее виде:

  • Описание угрозы.
  • Объект возможной атаки.
  • Риск.
  • Возможный сценарий атаки.
  • Предпринимаемые меры по устранению угрозы.

На последнем этапе процесса расставляются приоритеты по устранению угроз в зависимости от их риска. Это позволит заняться в первую очередь угрозами, которые могут нанести системе наибольший ущерб. Экономически невыгодно устранять абсолютно все определенные угрозы, поэтому возможно опустить угрозы, вероятность реализации которых стремится к нулю и ущерб от которых минимален. В итоге, для разработчиков информационной системы представляется документ, позволяющий им сформировать отчетливое понимание о потенциальных угрозах и рисках.

Литература

  1. Meier J. D., Mackman A., Dunner M., Vasireddy S., Escamilla R., Murukan A. Improving Web Application Security: Threats and Countermeasures [Электронный ресурс]. URL: http://msdn.microsoft.com/en-us/library/ff648644.aspx (дата обращения: 22.05.2015).
  2. The STRIDE Threat Model [Электронный ресурс]. URL: http://msdn.microsoft.com/en-us/library/ee823878%28v= cs.20%29.aspx (дата обращения: 10.05.2015).

References

  1. Meier J. D., Mackman A., Dunner M., Vasireddy S., Escamilla R., Murukan A. Improving Web Application Security: Threats and Countermeasures URL: http://msdn.microsoft.com/en-us/library/ff648644.aspx
  2. The STRIDE Threat Model . URL: http://msdn.microsoft.com/en-us/library/ee823878%28v= cs.20%29.aspx.