Сам себе «ИБшник»: как понять информационную безопасность с помощью Threagile

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

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

Как это сделать? В этом поможет такой инструмент, как Threagile. С его помощью можно построить модель информационной системы и получить отчёт о возможных угрозах.

Про модель угроз: зачем и кому нужна

Модель угроз необходимо создавать для компаний финансового сектора, а это в первую очередь банки и страховые компании, поскольку они обязаны проходить аудит. Но если говорить о российском рынке, то вообще все компании обязаны определять угрозы безопасности в соответствии с законом № 152-ФЗ «О персональных данных» (часть 2 статьи 19).

Методика определения угроз описана в приказе ФСТЭК России от 18 февраля 2013 года № 21 «О составе и содержании организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах».

В целом, мировая практика и локальные нормативные акты содержат похожие требования.

Почему стоит использовать именно автоматизированные инструменты?

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

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

Это может быть полезно системным аналитикам, которые хотят не только более полно спроектировать систему, но и расширить кругозор для развития карьеры.

Для проектного менеджера это позволяет запланировать необходимый объем работ, благодаря декомпозиции по задачам уже на этапе проработки архитектурного виденья. Также автоматизированные инструменты позволяют подготовить отчёт для руководства в удобном для представлении виде с понятными метриками.

Если говорить в общем, то моделирование угроз позволяет ответить на следующие вопросы:

Над чем мы работаем?
Что может пойти не так?
Что мы собираемся делать?
Достаточны ли применяемые меры?

Небольшая история для погружения в контекст

Когда я работал в зарубежном стартапе в роли архитектора решений, мы занимались подготовкой нового проекта к выходу на рынок. Директор тогда был обеспокоен тем, как же нам обеспечить безопасность системы. Первым делом я подготовил проект по внедрению практик DevSecOps, затем погрузился в построение модели угроз по методологии Stride, чтобы получить чёткий список действий для закрытия рисков. И уже после работ по этому блоку мы заказали пентест.

О выборе инструмента для построения модели угроз будет ниже.

Разработка проекта начинается с построения архитектурного виденья (Vision). Для примера я возьму Vision, сделанный в Structurizr, который состоит из нескольких компонентов: пользователи, внешняя система, веб-приложение, веб-сервис и БД. Это поможет нам сравнить представление, сгенерированное Threagile и представление, с которым работают архитекторы и аналитики.

Скрытый текст

workspace      model {         user = person "End User"         partner = person "Partner"         externalSystem = softwareSystem "External System" {             description "Interacts with the main system."             tags 'Ext'         }                  system = softwareSystem "Main System" {             api = container "Web Services" {                 description "Handles requests from users and partners."                 technology "Python"             }             adminPanel = container "Admin Panel" {                 description "Management interface for the system."                 technology "Python"             }             database = container "Database" {                 description "Stores application data."                 technology "Relational Database"             }          }         user -> externalSystem "Requests data from"         api -> database "Reads from and writes to"         adminPanel -> database "Accesses data from"         partner -> adminPanel "Interacts with"         externalSystem -> api "Sends data to"      }      views {         systemContext system {             include *             autolayout lr         }          container system {             include *             include user             autolayout lr         }           styles {             element "Person" {                 background #f9f9f9                 shape person             }             element "Container" {                 background #55aa55             }             element "Database" {                 shape cylinder             }             element "Ext" {                 background #f9f9f9             }         }     }  }

Выбор инструмента для моделирования угроз

Для построения модели угроз существует множество инструментов (некоторые из них перечислены на странице OWASP). Посмотрев разные варианты, я остановился на Threagile из-за его ключевых особенностей:

Это инструмент с открытым исходным кодом, выпущенном под лицензией MIT, что позволяет его использовать и в коммерческих целях.
В отличие от TMT и Threat dragon, Threagile предлагает отказаться от визуального построения диаграммы, и описать модель в YAML, что позволяет применить подход моделирования угроз as code для повышения прозрачности отслеживания изменений в системе контроля версий при работе в команде.
Дополнительно возможно определить свои правила обнаружения угроз, адаптированные к конкретным случаям использования.
Также инструмент может запускаться из командной строки или как REST-сервер, что позволяет интегрировать его в CI/CD.

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

диаграммы потоков данных,
отчёта о рисках в PDF,
таблицы Excel с рисками и оценкой угроз,
JSON-файлов с исходными данными для использования в автоматизации.

Мета-модель.

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

Если говорить упрощенно, то на вход для моделировании угроз нужно подать всего несколько типов элементов:

Данные, которые необходимо защитить.
Хранилища данных.
Программные компоненты, которые обрабатывают данные.
Внешние субъекты или системы, которые взаимодействуют с системой.
Потоки данных, которые описывают соединения между компонентами.

Оценив несколько вариантов, я решил, что Threagile подходит лучше всего, а платные я даже не рассматривал.

Как начать пользоваться Threagile

Проще всего начать построение модели с разделе Playground официального сайта и скачивания модели-заглушки.

Если уже установлен Docker, то можно выполнить команду для генерации файла модели заглушки (пример для Windows):

// запуск контейнера, который создаст модель-заглушку в текущей директории,  откуда была запущена команда  docker run --rm -it -v "$(pwd):/app/work" threagile/threagile  -create-stub-model -output /app/work

Затем можно открыть полученный файл threagile-stub-model.yaml в любом текстовом редакторе.

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

Раздел data_assets — активы данных

Активы данных — один из компонентов для процесса моделирования угроз, специально разработанный для представления различных типов данных, которые будут храниться, обрабатываться или передаваться в системе.

data_assets:   Customer data: # блок для описания данных партнеров     id: customer-data     description: Partners contract data     usage: business # values: business, devops     tags:     origin: Some Origin     owner: Some Owner     quantity: few # values: very-few, few, many, very-many     confidentiality: confidential # values: public, internal, restricted, confidential, strictly-confidential     integrity: critical # values: archive, operational, important, critical, mission-critical     availability: critical # values: archive, operational, important, critical, mission-critical     justification_cia_rating: Some Justification    End user data: # блок для описания данных конечных пользователей     id: end-user-data     description: End user PII     usage: business # values: business, devops     tags:     origin: User     owner: Some Owner     quantity: many # values: very-few, few, many, very-many     confidentiality: confidential # values: public, internal, restricted, confidential, strictly-confidential     integrity: critical # values: archive, operational, important, critical, mission-critical     availability: mission-critical # values: archive, operational, important, critical, mission-critical     justification_cia_rating: Some Justification

Некоторые поля заполняются значением из заданного справочника. Чтобы вывести все возможные значения справочников, нужно выполнить команду:

docker run --rm -it threagile/threagile -list-types

Вывод будет в формате:

Confidentiality: [public internal restricted confidential  strictly-confidential] Quantity: [very-few few many very-many]

Также будет удобно подключить валидацию yaml файла (в VS Code), с помощью схемы. Для этого можно добавить в самом начале yaml-файла строку:

# yaml-language-server:  $schema=https://raw.githubusercontent.com/Threagile/threagile/refs/heads/master/support/schema.json

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

Раздел technical_assets — технические активы

Под техническими активами понимаются различные сервисы или системы, которые обрабатывают, хранят и передают данные. Эти активы могут включать серверы, базы данных, приложения, API и другие технологические объекты.

Нам необходимо определить компоненты, которые необходимо описать, задать параметры, указать какими данными оперирует компонент в секции data_assets_processed, и куда данные направляются в разделе communication_links.

В коде ниже задано описание для БД, веб-приложения, веб-сервисов и внешней системы. Внешние системы помечаются как out_of_scope: true, чтобы исключить их из анализа.

technical_assets:

technical_assets:     DB:     id: db     description: DB     type: datastore # values: external-entity, process, datastore     usage: business # values: business, devops     used_as_client_by_human: false     out_of_scope: false     justification_out_of_scope:     size: service # values: system, service, application, component     technology: web-application # values: see help     tags:     internet: false     machine: virtual # values: physical, virtual, container, serverless     encryption: data-with-asymmetric-shared-key # values: none, transparent, data-with-symmetric-shared-key, data-with-asymmetric-shared-key, data-with-enduser-individual-key     owner: Some Owner     confidentiality: confidential # values: public, internal, restricted, confidential, strictly-confidential     integrity: critical # values: archive, operational, important, critical, mission-critical     availability: critical # values: archive, operational, important, critical, mission-critical     justification_cia_rating: Some Justification     multi_tenant: false     redundant: false     custom_developed_parts: false     data_assets_processed: # sequence of IDs to reference     data_assets_stored: # sequence of IDs to reference       - end-user-data       - customer-data     data_formats_accepted: # sequence of formats like: json, xml, serialization, file, csv       - xml     communication_links:       Admin panel:     id: admin-panel     description: Admin panel for customers     type: process # values: external-entity, process, datastore     usage: business # values: business, devops     used_as_client_by_human: true     out_of_scope: false     justification_out_of_scope:     size: application # values: system, service, application, component     technology: web-application # values: see help     tags:       - some-tag       - some-other-tag     internet: true     machine: virtual # values: physical, virtual, container, serverless     encryption: none # values: none, transparent, data-with-symmetric-shared-key, data-with-asymmetric-shared-key, data-with-enduser-individual-key     owner: Some Owner     confidentiality: confidential # values: public, internal, restricted, confidential, strictly-confidential     integrity: critical # values: archive, operational, important, critical, mission-critical     availability: critical # values: archive, operational, important, critical, mission-critical     justification_cia_rating: Some Justification     multi_tenant: false     redundant: false     custom_developed_parts: true     data_assets_processed: # sequence of IDs to reference       - end-user-data     data_assets_stored: # sequence of IDs to reference     data_formats_accepted: # sequence of formats like: json, xml, serialization, file, csv       - xml     communication_links:       db:         target: db         description: Some Description         protocol: odbc # values: see help         authentication: client-certificate # values: none, credentials, session-id, token, client-certificate, two-factor         authorization: technical-user # values: none, technical-user, enduser-identity-propagation         tags:         vpn: false         ip_filtered: false         readonly: false         usage: business # values: business, devops         data_assets_sent: # sequence of IDs to reference           - customer-data         data_assets_received: # sequence of IDs to reference           - end-user-data       Web services:     id: web-services     description: Web services for partners integration     type: process # values: external-entity, process, datastore     usage: business # values: business, devops     used_as_client_by_human: false     out_of_scope: false     justification_out_of_scope:     size: service # values: system, service, application, component     technology: web-service-rest # values: see help     tags:     internet: true     machine: virtual # values: physical, virtual, container, serverless     encryption: none # values: none, transparent, data-with-symmetric-shared-key, data-with-asymmetric-shared-key, data-with-enduser-individual-key     owner: Some Owner     confidentiality: confidential # values: public, internal, restricted, confidential, strictly-confidential     integrity: critical # values: archive, operational, important, critical, mission-critical     availability: critical # values: archive, operational, important, critical, mission-critical     justification_cia_rating: Some Justification     multi_tenant: false     redundant: false     custom_developed_parts: true     data_assets_processed: # sequence of IDs to reference       - end-user-data     data_assets_stored: # sequence of IDs to reference     data_formats_accepted: # sequence of formats like: json, xml, serialization, file, csv       - json     communication_links:       db:         target: db         description: Some Description         protocol: odbc # values: see help         authentication: client-certificate # values: none, credentials, session-id, token, client-certificate, two-factor         authorization: technical-user # values: none, technical-user, enduser-identity-propagation         tags:         vpn: false         ip_filtered: false         readonly: false         usage: business # values: business, devops         data_assets_sent: # sequence of IDs to reference           - end-user-data         data_assets_received: # sequence of IDs to reference     External:     id: ext     description: Web services for partners integration     type: process # values: external-entity, process, datastore     usage: business # values: business, devops     used_as_client_by_human: true     out_of_scope: true     justification_out_of_scope: Ext system     size: system # values: system, service, application, component     technology: web-service-rest # values: see help     tags:       - some-tag       - some-other-tag     internet: false     machine: virtual # values: physical, virtual, container, serverless     encryption: none # values: none, transparent, data-with-symmetric-shared-key, data-with-asymmetric-shared-key, data-with-enduser-individual-key     owner: Some Owner     confidentiality: confidential # values: public, internal, restricted, confidential, strictly-confidential     integrity: critical # values: archive, operational, important, critical, mission-critical     availability: critical # values: archive, operational, important, critical, mission-critical     justification_cia_rating: Some Justification     multi_tenant: false     redundant: false     custom_developed_parts: true     data_assets_processed: # sequence of IDs to reference       - end-user-data     data_assets_stored: # sequence of IDs to reference     data_formats_accepted: # sequence of formats like: json, xml, serialization, file, csv       - xml     communication_links:       ws:         target: web-services         description: Invoke REST API         protocol: https # values: see help         authentication: credentials # values: none, credentials, session-id, token, client-certificate, two-factor         authorization: technical-user # values: none, technical-user, enduser-identity-propagation         tags:         vpn: false         ip_filtered: false         readonly: false         usage: business # values: business, devops         data_assets_sent: # sequence of IDs to reference           - end-user-data         data_assets_received: # sequence of IDs to reference           - end-user-data

Раздел Trust_boundaries — доверенные границы

Данный раздел служит для указания систем, находящихся в доверенном контуре.

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

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

trust_boundaries:   AWS Trust Boundary:     id: aws-network     description: Some Description     type: network-dedicated-hoster # values: see help     tags:     technical_assets_inside: # sequence of IDs to reference       - admin-panel       - web-services       - db     trust_boundaries_nested: # sequence of IDs to reference

Доверенных контуров может быть несколько. Например, некоторые ресурсы могут быть размещены в облаке, а другие — на кластере серверов в дата-центре или могут быть вложены друг в друга.

Несколько примеров:

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

Раздел shared_runtimes — общие среды выполнения

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

shared_runtimes:   Some Shared Runtime:     id: some-runtime     description: Some Description     tags:     technical_assets_running: # sequence of IDs to reference       - admin-panel       - web-services

Построение отчёта

Заполнив перечисленные выше разделы, можно перейти к построению отчёта. Для этого нужно или загрузить файл на странице run.threagile.io или выполнить команду:

# Запускает Docker, монтирует текущий каталог в /app/work внутри контейнера  # и обрабатывает указанный YAML файл для генерации результата в том же каталоге  docker run --rm -it -v "$(pwd):/app/work" threagile/threagile -verbose  -model /app/work/threagile-stub-model.yaml -output /app/work

После отработки процесса в папке, откуда был произведён запуск, будет сгенерирован отчёт и набор файлов:

data-asset-diagram.png — диаграмма активов данных;
data-flow-diagram.png — диаграмма потоков данных;
risks.json — список рисков в формате JSON для автоматизированной обработки;
risks.xlsx — список рисков в формате XLSX;
stats.json — статистика по рискам;
tags.xlsx — список тэгов;
technical-assets.json — список технических активов в формате JSON для автоматизированной обработки.

Диаграмма потоков данных data-flow-diagram.png в отчёте, построенном по модели-примеру, выглядит так:

По ней видно, что внешняя система обращается к веб-сервису REST, находящемуся в доверенном контуре, и передаёт данные пользователей, которые сохраняются в БД.

Если сравнить с архитектурным видением, представленным в начале статьи, то можно увидеть, что данная диаграмма крайне схожа, что позволяет понимать её всем специалистам. На диаграмме нет пользователей, но присутствуют дополнительные атрибуты, такие как протоколы взаимодействия и оценка относительной привлекательности для злоумышленника (RAA — Relative Attacker Attractiveness). То есть подсвечиваются ресурсы, которым стоит уделить больше внимания.

Диаграмма активов данных data-asset-diagram.png позволяет понять, где указанные данные будут использованы:

Также файлы, которые мы получим, содержат отчёт — report.pdf. Типичное содержание отчёта.

Резюме для руководства содержит представление с удобными для оценки метриками уровня риска и их статусом:

И автоматически проведённый анализ влияния:

Страница со статусом рисков после анализа:

Управление рисками

Чтобы перейти к управлению рисками, необходимо сделать пояснения.

Почему рекомендуется использовать риск-ориентированный подход?

У нас есть так называемый жизненный цикл управления рисками, который состоит из следующих этапов:

Определение риска.
Оценка.
Снижение.
Планирование.
Мониторинг.

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

Уменьшить воздействие.
Снизить вероятность.
Переложить риск (на страховую компанию или субподрядчика).
Избежать риска (временное отдаление объекта от угрозы).

Так вот, риск-ориентированный подход предполагает выявление рисков и устранение дефектов на ранней стадии — до того, как они перерастут в серьёзные проблемы.

И до того, как на это укажет отдел информационной безопасности.

Риск-ориентированный подход является приоритетным благодаря своей эффективности и позволяет достичь следующих преимуществ:

Приоритизация ресурсов для закрытия угроз с высоким уровнем.
Адаптивность к изменяющимся условиям.
Непрерывный мониторинг.
Повышение прозрачности и подотчётности.
Управление качеством.

Для этого как раз и нужен Threagile, что позволяет без особых затрат выявить угрозы и управлять ими.

Категории рисков

Threagile использует модель рисков STRIDE — это широко используемая методология моделирования угроз, разработанная компанией Microsoft в конце 1990-х годов. Она обеспечивает структурированный подход к выявлению потенциальных угроз для программных систем, классифицируя их по шести основным типам:

Spoofing (подмена): злоумышленники выдают себя за легитимного пользователя, приложение или организацию, чтобы получить несанкционированный доступ или привилегии.
Tampering (нелегитимное изменение): несанкционированное изменение данных, как при хранении, так и при передаче.
Repudiation (отказ от ответственности): пользователи, совершив какую-то операцию, отрицают свои действия. Например, пользователь, который покупает товар, должен расписаться на квитанции при получении товара. Продавец может использовать эту квитанцию как доказательство того, что покупатель уже получил товар. Здесь важно ввести такое понятие, как неподдельность операции, которое означает способность системы учитывать угрозы отказа от ответственности.
Information disclosure (раскрытие информации): передача конфиденциальной информации неавторизованным лицам.
DoS (отказ в обслуживании): нарушение доступности системы или ресурса для легитимных пользователей.
Elevation of privilege (повышение привилегий): получение более высокого уровня доступа или разрешений, чем предполагалось.

Если открыть файл risks.xlsx, то можно увидеть список рисков с заданной категорией, с оценкой и привязкой к компоненту.

Как подготовить список задач для команды разработки на основе отчёта?

Полученный отчёт содержит список рисков применительно к компоненту системы, и, что мне нравится больше всего, это ссылки на OWASP cheat sheet, где можно найти практические рекомендации по мерам, которые необходимо применить для снижения рисков.

Для примера ссылка по мерам защиты от SQL-инъекций. В разделе отчёта Риски по категориям уязвимости (Risks by Vulnerability Category), можно найти хорошо известные уязвимости, например Cross-Site Scripting (XSS), SQL/NoSQL-Injection или Unguarded Access From Internet.

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

Управление рисками в Threagile

После исполнения задач по устранению уязвимостей можно указать в YAML-файле модели, что риск был рассмотрен, оценён, принят (или нет) и в итоге устранён.

Секция risk_tracking позволяет применить подход risk management as code. После первой генерации отчёта, каждому риску присваивается уникальный идентификатор. Эти уникальные идентификаторы рисков отражены в PDF-отчете и в Excel-файле (колонка «ID»), а также в JSON-файлах.

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

Также возможно добавить дополнительные риски в раздел individual_risk_categories.

Что дополнительно позволяет Threagile

Для генерации примера расширенной модели, которая оперирует большим списком активов, и отчета по ней, нужно выполнить следующие команды:

# запуск докер-контейнера с образом threagie с передачей команды  для генерации модели-заглушки docker run --rm -it -v "$(pwd):/app/work" threagile/threagile  -create-stub-model -output /app/wor  k# если необходимо добавить в уже созданную модель pipeline сборки приложения docker run --rm -it -v "$(pwd)":/app/work threagile/threagile  --model /app/work/threagile.yaml --output /app/work  --execute-model-macro add-build-pipeline  # запуск докер-контейнера для генерации отчёта в текущей папке на основе  модели-заглушки docker run --rm -it -v "$(pwd):/app/work" threagile/threagile -verbose  -model /app/work/threagile-stub-model.yaml -output /app/work

После выполнения данных команд мы можем больше понять о возможностях системы.

abuse_cases — содержит дополнительные примеры случаев злоупотребления, таких как кража данных и компрометация систем, что позволит записать это в риски и подумать о том, как защититься от этих угроз.
security_requirements — позволяет прописать дополнительные требования к обеспечению безопасности. Например, для компаний, оперирующих платёжными данными, можно задать требования из PCI DSS (Стандарт безопасности данных индустрии платежных карт).
data_assets — здесь видно, что в качестве активов данных мы можем задать не только данные клиентов, заказов, но и бэкапы, аналитические данные, а также исходный код приложений.
technical_assets — в данный раздел добавляются дополнительные компоненты, чтобы раскрыть возможность глубокой проработки модели со всеми деталями. Можно увидеть, что модель позволяет описать взаимодействие клиента с нашим приложением через балансировщик, с авторизацией через Keycloack и передачу данных внутри контура системы с помощью секции communication_links между сервисами, внутренними системами и хранилищами. А также модель позволяет описать build-pipeline для построения защиты процесса сборки приложения от исходного кода до деплоя.
trust_boundaries — позволяет задать подсети от DMZ, это точка контакта нашей системы с внешним миром, до внутренних хранилищ данных и репозитория с исходным кодом.
individual_risk_categories — этот раздел содержит пример вручную заданных рисков.

Подводя итог

На этом этапе мы можем закончить знакомство с моделированием угроз в Threagile.

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

С точки зрения ИБ процесс обеспечения защиты данных состоит из следующих шагов:

Идентификация.
Категоризация.
Маркировка.
Разработка мер защиты.
Мониторинг и сопровождение.

Как видно, Threagile позволяет идентифицировать и категоризировать данные, а также разработать меры защиты и мониторить их, сделав первые шаги в защите информации.

Что могу ещё сказать про Threagile?

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

А что с историей, которую я рассказал в начале?

«Давным-давно», работая в компании N, на запрос гендиректора усилить безопасность, я нашел Threagile, пробежался по документации и собрав отчёт за неделю, передал его программистам и DevOps-инженерам, вследствие чего мы позакрывали риски и смогли выпустить на рынок безопасное приложение.

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

Таким образом, чтобы попробовать сделать анализ угроз своей системы нужно выполнить несколько шагов:

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

Попробуйте.

Полезные ссылки из статьи

ссылка на оригинал статьи https://habr.com/ru/articles/879780/