07.02.2025 08:26
msfs11 0 375 Источник

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

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

Как это сделать? В этом поможет такой инструмент, как 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. Типичное содержание отчёта.

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

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

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

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

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

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

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

  1. Определение риска.

  2. Оценка.

  3. Снижение.

  4. Планирование.

  5. Мониторинг.

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

  • Уменьшить воздействие.

  • Снизить вероятность.

  • Переложить риск (на страховую компанию или субподрядчика).

  • Избежать риска (временное отдаление объекта от угрозы).

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

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

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

  1. Приоритизация ресурсов для закрытия угроз с высоким уровнем.

  2. Адаптивность к изменяющимся условиям.

  3. Непрерывный мониторинг.

  4. Повышение прозрачности и подотчётности.

  5. Управление качеством.

Для этого как раз и нужен 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-инженерам, вследствие чего мы позакрывали риски и смогли выпустить на рынок безопасное приложение.

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

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

  1. Скачать файл модели с примером с официального сайта.

  2. Отредактировать файл модели в любом текстовом редакторе, задав категории данных и компоненты системы.

  3. Получить отчёт.

Попробуйте.

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

Комментарии (0)