Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов.

Под практикой подразумевается набор мер, который может быть встроен в один из этапов SDLC/DevOps (Threat modeling, SAST, DAST, SCA, Docker image scanning, Kubernetes scanning, AWS Audit и так далее).

Оглавление

• Dev

  • Threat Modeling

  • Статический анализ приложений на уязвимости (SAST)

  • Проверка open-source компонент - SCA

  • Поиск секретов

  • Динамический анализ приложений на уязвимости (DAST)

  • Тестирование по принципам Behaviour Driven Development

  • Сканирование образов Docker

• Ops

  • Kubernetes Security

  • Vulnerability Management

  • Public Cloud Security

• И это еще не все?

Dev

Threat Modeling

Моделирование угроз в контексте Secure Development Lifecycle представляет из себя процесс анализа архитектуры ПО на предмет наличия в ней потенциальных уязвимостей и небезопасных технологий. Чтобы сократить расходы на добавление дополнительного функционала с точки зрения безопасности, решением может являться внедрение процесса проверок ИБ еще на этапе проектирования архитектуры. На этом же этапе формируются требования со стороны специалистов по безопасности приложений, которые в дальнейшем пойдут в backlog. Подобный подход прибегается, на самом деле, во всех практиках DevSecOps и получил устойчивое выражение Shift security to the left.

Чтобы данный процесс нашел место в современной разработке при высокой скорости выхода релизов в крупной IT-компании, процесс моделирования угроз должен быть также автоматизирован. Вот некоторый пул open-source инструментов, которые могут помочь.

OWASP Threat Dragon

Ссылка на OWASP Threat Dragon

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

Pytm

Ссылка на Pytm

Pytm - фреймворк на Python для создания диаграмм потоков данных и списка угроз системы.

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

Materialize threats tool

Ссылка на Materialize threats tool

Materialize-threats - фреймворк на Python, который позволяет конвертировать схемы архитектуры ПО из сервиса draw.io в графы, сохранить их в базу и в дальнейшем работать с утверждениями относительно этих графов при помощи SQL запросов. Помимо этого инструмент умеет формировать тесты на Gherkin.

Это любопытный open-source инструмент, который хорошо описывает то, куда двигаются современные Enterpise-решения по моделированию угроз вроде Irius Risks.

Сценарий работы с ним следующий:

1. Создание диаграммы взаимодействия компонентов в .drawio, согласно вашему data flow

2. Выделение доверенных зон на диаграмме, согласно Rapid Threat Model Prototyping methodology(в readme есть пояснение)

3. Сохранение файла .drawio

4. Запуск materialize.py с импортом файла .drawio

5. Получение сценария реализации угроз в формате Gherkin.

Не будем долго останавливаться на других инструментах ибо принцип работы везде похожий.

Вот еще несколько open-source инструментов по части моделирования угроз:

• Threatspec

• Raindance

• Microsoft Threat Modeling Tool

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

• Awesome threat modeling

Статический анализ приложений на уязвимости (SAST):

Переходим к этапу тестирования, а именно статическому анализу кода . Анализаторов кода существует огромное количество. Open-source инструменты, в свою очередь, выделяются тем, что они написаны под какой-то конкретный язык. Большое количество инструментов можно найти в следующих подборках:

• OWASP Source Code Analysis Tools

• Static Analysis Tools

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

Salus

Ссылка на Salus

Образ контейнера, в который помещено сразу несколько статических анализаторов, вроде Bandit, Gosec, Brakeman, а также анализаторы open-source компонентов (Ruby,Node.js, Python,Go). Запускается это следующим образом:

# Navigate to the root directory of the project you want to run Salus on$ cd /path/to/repo# Run the following line while in the root directory (No edits necessary)$ docker run --rm -t -v $(pwd):/home/repo coinbase/salus

На выходе получаем JSON/YAML отчет. На GitHub также можно найти описание встраивания в CircleCI.

ShiftLeft Scan

Ссылка на ShiftLeft Scan

Инструмент работает по аналогии с Salus, но с поддержкой большего количества статических анализаторов. В репо можно посмотреть те статические анализаторы, которые были помещены в docker образ (gosec, find-sec-bugs, psalm, bandit, ). В образ Docker поместили даже анализаторы terraform, bash, kubernetes манифестов.

Пример запуска статического анализа Python проекта:

$ docker run --rm -e "WORKSPACE=${PWD}" -v "$PWD:/app" shiftleft/sast-scan scan --src /app --type python

Более того, к инструменту есть интеграция с IDE.

GitLab SAST

Ссылка на описание SAST в GitLab

Gitlab является довольно популярной DevOps платформой, но что еще в ней есть, так это бесплатный набор разных open-source SAST, которые можно подключить из коробки в пайплайн. В Gitlab также есть возможность встроить SCA, поиск секретов, fuzzing и другие практики DevSecOps, но централизованное управление всеми средствами будет доступно только в Gold-версии.

LGTM

Ссылка на LGTM

LGTM - облачная платформа для сканирования кода от компании Semmle, которая в конце того года стала частью GitHub. Semmle также являются автором CodeQL, применение которого было анонсировано GitHub на своей онлайн-конференции Satellite.

Semgrep

Ссылка на облачную версию Semgrep

Уникальный проект, про который хотелось бы написать отдельную статью. По сути это не столько статический анализатор кода на наличие уязвимостей, сколько фреймворк, под капотом которого находится AST и Data flow, который можно использовать по разным назначениям. Например, можно сформировать следующий запрос:

$ semgrep --config=<path/to/config> path/to/src

Конфигурационный файл для semgrep пусть будет следующим:

rules:- id: user-eval  patterns:  - pattern-inside: |      def $F(...):        ...  - pattern-either:    - pattern: eval(..., request.$W.get(...), ...)    - pattern: |        $V = request.$W.get(...)        ...        eval(..., $V, ...)    - pattern: eval(..., request.$W(...), ...)    - pattern: |        $V = request.$W(...)        ...        eval(..., $V, ...)    - pattern: eval(..., request.$W[...], ...)    - pattern: |        $V = request.$W[...]        ...        eval(..., $V, ...)

В результате Semgrep будет находить инъекции вроде тех, что отображены ниже на скриншоте (желтым отмечены те строки, которые semgrep посчитал уязвимыми):

Примечание. На мой взгляд, большой проблемой во многих open-source инструментах, особенно в SAST, так это отсутствие унификации по части вывода результатов. Очень малая часть этих инструментов предоставляет CWE к найденным срабатываниям, из-за чего возникают проблемы на уровне менеджмента уязвимостей. На текущий момент все коммерческие решения, которые я знаю, приводят результат найденных уязвимостей к CWE и CVE.

Проверка open-source компонент - SCA

Наряду с тем кодом, разработка которого выполняется внутри команды, необходимо также проверить open-source, который подключается к проекту. Отсутствие процесса анализа сторонних компонент на наличие уязвимостей может существенно повлиять на безопасность продукта (как например, это случилось с компанией Equifax). Принципы работы, сравнение популярных инструментов SCA я приводил в отдельной статье, а здесь мы поговорим о том, какие существуют инструменты.

Dependency Check

Ссылка на Dependency Check

Dependency Check - одно из самых популярных open-source решений от OWASP для проверки сторонних компонентов . Существует большое количество готовых интеграций, способов встраивания в пайплайн, но у инструмента есть куда развиваться в сторону качества. Рекомендуется к внедрению для компаний, где процессы Secure SDLC находятся на начальных этапах и у специалистов со стороны ИБ есть время для разбора ложных срабатываний. У Dependency Check нет единой платформы, в которой можно отслеживать результаты в ретроспективе, поэтому, если процессы менеджмента уязвимостей в организации не выстроены, стоит обратить внимание на Dependency Track.

# Dependency Check Maven Plugin example$ mvn org.owasp:dependency-check-maven:check

Dependency Track

Ссылка на сайте Dependency Track

Dependency Track - второе по популярности решение от OWASP, которое представляет из себя веб-платформу, принимающую на вход Software bill of materials (SBOM) от другого инструмента CycloneDx. Dependency Track исследует BOM, после чего обращается в общедоступные базы данных уязвимостей, например, NVD. Инструмент имеет также возможность интегрироваться со Slack, Microsoft Teams, сканировать репозитории артефактов и проверять сторонние компоненты на лицензионную чистоту.

# CycloneDx Maven Plugin example to make SBOM$ mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom

Snyk Open-source

Ссылка на официальном сайте Snyk Open-source

Компания Snyk кроме того, что развивает свою коммерческую платформу для сканирования open-source компонентов в проектах, также предоставляет бесплатную версию в виде SaaS-решения. Проекты можно подгружать как через репозиторий (GitHub, Bitbucket), так и через CLI.

Как может выглядеть сканирование snyk для npm:

$ npm install -g snyk$ snyk auth$ snyk monitor

Sonatype Open-source

Помимо NVD (основного источника информации об уязвимостях для большинства решений) существует база Sonatype OSS, поддерживаемая компанией Sonatype, у которой также есть коммерческое решение Nexus IQ. Мы, в свою очередь, взяли на вооружение Nexus IQ как основной инструмент SCA для наших заказчиков. Sonatype OSS - база данных уязвимостей, которая может быть подключена инструментами Dependency Check и Dependency Track. Кроме того, Sonatype поддерживает следующие open-source инструменты SCA, которые могут быть использованы для сканирования зависимостей и берут данные из Sonatype OSS:

• Nexus Vulnerability Scanner - универсальный сканер от Sonatype

• AuditJS - сканер JS (NPM, Angular, yarn, bower)

• Nancy - сканер Golang

• Jake - сканер Conda

• Chelsea - сканер Ruby

• Cheque - сканер C/C++ (GCC)

• Ahab - сканер apt, apk, yum, dnf пакетов

• Pants - сканер Rust (Cargo)

• Sonatype Depshield - сканер GitHub проектов

Другие материалы по SCA:

• Большая подборка SCA от OWASP

• ClearlyDefined

• Renovate - бесплатная платформа от White Source

• Dependabot - бот GitHub для проверки open-source в репозиториях GitHub

Поиск секретов

Проект может содержать не только уязвимости, которые были допущены в собственном коде и open-source компонентах, но секреты вроде паролей, токенов, закрытых ключей. Разумеется, если в коде содержится открытый пароль от критически важной базы данных, допускать его в репозиторий нежелательно. С этой целью существует ряд инструментов, которые могут помочь отыскать открытые секреты. Здесь мы не будем долго останавливаться, ибо принцип работы везде одинаковый.

git-secrets

Ссылка на официальном сайте git-secrets

$ git secrets --scan /path/to/file

Gitrob

Ссылка на gitrob

$ export GITROB_ACCESS_TOKEN=<TOKEN>$ gitrob <target>

Gitleaks

Ссылка на gitleaks

$ gitleaks --repo-path=<path to repo>$ gitleaks --repo=<url of github>

Также есть в виде Github-action.

TruffleHog

Ссылка на TruffleHog

$ trufflehog [-h] [--json] [--regex] [--rules RULES]                  [--entropy DO_ENTROPY] [--since_commit SINCE_COMMIT]                  [--max_depth MAX_DEPTH]                  git_url

TruffleHog - самый известный инструмент в сообществе, осуществляющий поиск секретов как по регулярным выражениям, так и прибегая к оценки энтропии методом Шеннона.

GitGuardian

Ссылка на GitGuardian

SaaS платформа для поиска секретов. Есть также коммерческая on-prem версия. В России не продается.

Примечание. Для хранения секретов и сокрытия их в исходном коде и конфигурационных файлах необходимо использовать решения класса Password Vault (HashiCorp Vault, conjur, )

Динамический анализ приложений на уязвимости (DAST):

Arachni

Ссылка на Arachni

Одно из моих любимых open-source решений, в первую очередь за свою точность. Есть возможность развертывания в виде Docker-контейнера, CLI и веб-интерфейса. Жаль, что решение перестало поддерживаться разработчиками. Результаты выводятся в CWE-формате.

Способ сканирования через Docker:

$ docker run -d \    -p 222:22 \    -p 7331:7331 \    -p 9292:9292 \    --name arachni \    arachni/arachni:latest

После развертывания контейнера, запуск сканирования и выгрузка отчетов происходит через REST API по порту 7331 в виде json.

OWASP ZAP

Ссылка на OWASP ZAP

Одно из самых популярных open-source решений, которое может быть встроено в CI/CD. Имеет свой GUI, может быть развернуто в виде CLI или docker-контейнера. Также есть режим работы в виде прокси.

# OWASP ZAP as a daemondocker run -p 8090:8090 -i owasp/zap2docker-stable zap.sh -daemon -port 8090 -host 0.0.0.0# OWASP ZAP runs for 1  minute and then waits for the passive scanning to complete before reporting the results.docker run -t owasp/zap2docker-weekly zap-baseline.py -t https://www.example.com

Есть даже кастомные сценарии развертывания в виде Kubernetes-оператора.

Кроме того, оно очень быстрое. Проект, который Arachni анализирует 10 минут, ZAP может просканировать за пару минут, однако за такую скорость приходится, как правило, платить не самым точным результатом.

w3af

Ссылка на w3af

Несмотря на то, что инструмент давно не обновляется и не обозревается аналитиками (например, наиболее свежий обзор в журнале Хакер датируется 2012 годом (http://personeltest.ru/aways/xakep.ru/2012/11/09/w3af-pentest/)), тем не менее есть официальный docker-контейнер и инструкции по встраиванию сканера в CI/CD

Вот например, автор встроил разные open-source решения по безопасности в пайплайн Jenkins на AWS, включая w3af.

Пример сканирования через docker:

$ git clone https://github.com/andresriancho/w3af.git$ cd w3af/extras/docker/scripts/$ sudo ./w3af_console_docker

Примечание. Динамический анализ бывает не только для веб-приложений. Более полный список можно увидеть здесь.

Стоит отметить про отдельный класс решений для динамического сканирования мобильных приложений, open-source инструментов и enterprise, которых весьма мало. Мы в частности занимаемся разработкой собственного инструмента DAST для мобильных приложений.

Тестирование по принципам Behaviour Driven Development

Behavioral Driven Development (BDD) (или разработка через поведение)- подход в разработке ПО, который произошел от Test Driven Development (TDD) (разработка через тестирование). Несмотря на том, что эти подходы, как итог, стали применяться для разных целей и использовать разные инструменты, их применение можно найти и в сфере безопасности. Основная концепция BDD в описании пользовательских сценариев тестирования с помощью человеко-читаемоего языка Gherkin.

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

Gauntlt

Ссылка на Gauntlt

Guantlt - фреймворк, использующий концепцию Behavioral Driven Development. Он автоматизировать сканирование с помощью различных инструментов и позволяет описать Arachni, nmap, sslyze, sqlmap и другие инструменты на языке Gherkin.

# nmap-simple.attackFeature: simple nmap attack to check for open ports  Background:    Given "nmap" is installed    And the following profile:      | name     | value       |      | hostname | example.com |  Scenario: Check standard web ports    When I launch an "nmap" attack with:      """      nmap -F <hostname>      """    Then the output should match /80.tcp\s+open/    Then the output should not match:      """      25\/tcp\s+open      """

Таким образом, Guantlt может стать мостиком между командами разработки, безопасности и менеджмента.

Примечание. Аналогом Guantlt является BDD-Security, который в поддерживаемых инструментах имеет также OWASP ZAP, Tenable Nessus Scanner.

Сканирование образов Docker:

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

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

Пройдемся по некоторым из инструментов.

Clair

Ссылка на Clair

Инструмент для проверки слоев образа на общедоступные CVE уязвимости. У инструмента отсутствует из коробки UI для работы, поэтому необходимо подключать сторонние инструменты вроде Klar.

$ docker run -d -e POSTGRES_PASSWORD="" -p 5432:5432 postgres:9.6$ docker run --net=host -d -p 6060-6061:6060-6061 -v $PWD/clair_config:/config quay.io/coreos/clair:latest -config=/config/config.yaml

Klar

Ссылка на Klar

Утилита для взаимодействия с API Clair.

$ mkdir klar && cd klar && wget https://github.com/optiopay/klar/releases/download/v2.4.0/klar-2.4.0-linux-amd64 -O klar && chmod +x klar$ CLAIR_ADDR=http: //localhost:6060 CLAIR_THRESHOLD=10 ./klar <docker image>

Trivy

Ссылка на Trivy

Trivy находит уязвимости сборок ОС (поддерживаются Alpine, RedHat (EL), CentOS, Debian GNU, Ubuntu) и проблемы в зависимостях (Gemfile.lock, Pipfile.lock, composer.lock, package-lock.json, yarn.lock, Cargo.lock) В отличие от Clair умеет сканировать как в репозитории, так и локально, или на основании переданного .tar файла с Docker образом.

# Download bin$ wget https: //github.com/knqyf263/trivy/releases/download/v0.1.3/trivy_0.1.3_Linux-64bit.deb$ dpkg -i ./trivy_0. 1 .3_Linux-64bit.deb# Scan image$ trivy bkimminich/juice-shop# Scan image in tar$ trivy -i ./ my_saved_docker_image.tar

Anchore

Ссылка на Anchore

Популярный инструмент для сканирования образов Docker. Есть возможность работы через REST API или CLI.

$ anchore-cli --u admin --p foobar image add httpd:latest$ anchore-cli --u admin --p foobar image vuln httpd:latest all

AquaMicroscanner

Ссылка на AquaMicroscanner

Инструмент от Aqua Security, который развивается параллельно вместе с Trivy.

$ docker run --rm -it aquasec/microscanner --register <email address>

ADD https://get.aquasec.com/microscanner /RUN chmod +x /microscannerRUN /microscanner <TOKEN> [--continue-on-failure]

Примечание. Сравнение инструментов по сканированию образов на общедоступные CVE можно почитать здесь:

• Testing docker CVE scanners. Part 1: false negatives and what they mean for your security

• Testing Docker CVE Scanners. Part 2: How good is package detection?

• Testing docker CVE scanners. Part 2.5 Exploiting CVE scanners

• Testing Docker CVE scanners. Part 3: Test it yourself / Conclusions

Dagda

Ссылка на Dagda

Dagda выделяется тем, что имеет под капотом Dependency Check, Retire.js и ClamAV для поиска вредоносных программ.

$ export DAGDA_HOST='127.0.0.1'$ export DAGDA_PORT=5000$ python3 dagda.py vuln --init$ python3 dagda.py check --docker_image jboss/wildfly

Docker bench

Ссылка на Docker Bench

Docker bench - инструмент для compliance-проверок как образов, так и контейнеров и хостов.
Основной набор проверок строится на базе документа CIS Benchmarks для Docker.

$ docker run -it --net host --pid host --userns host --cap-add audit_control \      -e DOCKER_CONTENT_TRUST=$DOCKER_CONTENT_TRUST \      -v /etc:/etc:ro \      -v /usr/bin/containerd:/usr/bin/containerd:ro \      -v /usr/bin/runc:/usr/bin/runc:ro \      -v /usr/lib/systemd:/usr/lib/systemd:ro \      -v /var/lib:/var/lib:ro \      -v /var/run/docker.sock:/var/run/docker.sock:ro \      --label docker_bench_security \      docker/docker-bench-security

Dockle

Ссылка на Dockle

Инструмент для выполнения compliance-проверок, в том числе, выходящих за рамки CIS.

$ docker run --rm goodwithtech/dockle:v${DOCKLE_LATEST} [YOUR_IMAGE_NAME]

Ops:

Kubernetes Security

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

Дополнительный материал для расширения подборки:

My Arsenal of Cloud Native (Security) Tools by MARCO LANCINI

Kube-bench

Ссылка на Kube-bench

Еще один (и не последний) инструмент от компании Aqua Security. Инструмент выполняет проверки CIS Kubernetes Benchmark для развернутых рабочих нагрузок Kubernetes (в том числе GKE, EKS and AKS)

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

# Run inside a container$ docker run --rm --pid=host                      \   -v $(which kubectl):/usr/bin/kubectl         \   -t aquasec/kube-bench:latest <master|node># Run in a cluster - on master node$ kubectl run                                          \      --rm                                             \      -it                                              \      kube-bench-master                                \      --image=aquasec/kube-bench:latest                \      --restart=Never                                  \      --overrides="{ \"apiVersion\": \"v1\",           \          \"spec\": { \"hostPID\": true,               \          \"nodeSelector\":                            \          { \"kubernetes.io/role\": \"master\" },      \          \"tolerations\": [ {                         \          \"key\": \"node-role.kubernetes.io/master\", \          \"operator\": \"Exists\",                    \          \"effect\": \"NoSchedule\" }]}}"             \      -- master                                        \      --version 1.8# Run in a cluster - on worker nodes$ kubectl run                                \      --rm                                   \      -it                                    \      kube-bench-node                        \      --image=aquasec/kube-bench:latest      \      --restart=Never                        \      --overrides="{ \"apiVersion\": \"v1\", \          \"spec\": { \"hostPID\": true } }" \      -- node                                \      --version 1.8

Kubernetes Auto Analyzer

Ссылка на Kubernetes Auto Analyzer

Инструмент работает по тому же принципу, что и Kube-bench, но в отличие от него перестал поддерживаться. Сами авторы инструмента предлагают продолжить пользоваться Kube-bench от Aqua Security.

# Put the config file in a directory and mount it to the /data folder$ docker run --rm                               \      -v /data:/data raesene/kube_auto_analyzer \      -c /data/admin.conf -r testdock# Provide a KUBECONFIG file to identify and authenticate the session$ kubeautoanalyzer -c <kubeconfig_file_name> -r <report_name> --html

Kube-hunter

Ссылка на Kube-hunter

Инструмент для имитации тестирования на проникновения Kubernetes. Может быть запущен на сервере кластера, внутри контейнера или на удаленном компьютере с указанием IP-адреса / доменного имени кластера Kubernetes.

# Run from docker$ docker run -it --rm --network host aquasec/kube-hunter# Run from kubectl$ kubectl run --rm -it                        \     kube-hunter                            \     --image=aquasec/kube-hunter            \     --restart=Never                        \     --overrides="{ \"apiVersion\": \"v1\", \     \"spec\": { \"hostNetwork\": true } }"

KubiScan

Ссылка на KubiScan

Инструмент для проверки выданных разрешений RBAC-модели Kubernetes.

Кстати, проверке выданных разрешений посвящена отдельная неплохая статья на сайте CyberARK.

# Run from MASTER node$ docker run -it --rm -e CONF_PATH=~/.kube/config -v /:/tmp cyberark/kubiscan [CMD]# Search for pods with privileged accounts$ kubiscan -rp# Show all risky subjects (users, service accounts, groups)$ kubiscan -rs# Show all the rules a service account has$ kubiscan -aars "SANAME" -ns "default" -k "ServiceAccount"# List service account RoleBindings$ kubiscan -aarbs "SANAME" -ns "default" -k "ServiceAccount"

Krane

Ссылка на Krane

Инструмент, выполняющий статический анализ RBAC за счет индексации объектов RBAC в RedisGraph. Управление рисками RBAC происходит через настройку политик. Krane может работать как CLI, docker-контейнер или автономная служба для непрерывного анализа, а также быть встроенным в CI/CD.

Statboard

Ссылка на Starboard

Инструмент, позволяющий нативно интегрировать инструменты безопасности в среду Kubernetes благодаря CustomResourceDefinitions (CRDs) для работы с такими инструментами как trivy, kube-bench, kube-hunter. Starboard предоставляет также kubectl-совместимый инструмент командной строки и плагин Octant, который делает отчеты о безопасности доступными через знакомые инструменты Kubernetes.

$ starboard find vulnerabilities deployment/nginx --namespace dev$ starboard get vulnerabilities deployment/nginx \  --namespace dev \  --output yaml

Kubeaudit

Ссылка на Kubeaudit

Еще один инструмент, выполняющий проверки Kubernetes.

# Run from kubectl (as plugin)$ kubectl audit all

Kubesec

Ссылка на Kubesec

Последний легковесный инструмент для проверки Kubernetes в этой подборке.

$ krew install kubesec-scan$ kubectl kubesec-scan pod <podname>

Deepfence Runtime Threat Mapper

Ссылка на Deepfence Runtime Threat Mapper

Бесплатная community-версия комплексного решения по защите облачных нагрузок. Платформа отображает рабочие нагрузки на графе, ищет аномалии в поведении с помощью агентов сканирования, интегрируется с CI/CD для сканирования образов, а также выполняет поиск уязвимостей образов в заданном Registry. Также есть интеграция с SIEM, Slack, Jira, Amazon S3 (неполный список интеграций).

Sysdig Falco

Ссылка на Sysdig Falco

Бесплатная версия решения для защиты в режиме run-time от Sysdig, хорошо себя зарекомендовавшая в сообществе.

Vulnerability Management

Можно выполнять огромное количество различных сканирований инструментами SAST, DAST, SCA, анализаторами образов Docker и конфигурации Kubernetes, но без правильно построенного процесса управления выявленными уязвимостями и распределения ответственных процесс устранения выявленных дефектов может очень сильно затянуться. Решения класса Vulnerability Management призваны помочь в этом вопросе. Как правило, это единая точка входа всех выявленных уязвимостей посредством взаимодействия через API или при помощи веб-интерфейса с целью дальнейшей визуализации и экспорта структурированной информации в дефект-трекинг. Мы в своих практиках используем коммерческое решение собственной разработки AppSec.Hub, которое помимо управления уязвимостями, умеет также создавать и экспортировать готовые DevSecOps-пайплайны в CI/CD системы. Но в этой статье мы коснемся только open-source решений.

DefectDojo

Ссылка на DefectDojo

Решение для управление уязвимостями от OWASP. Есть много интеграций (22+) как с open-source сканерами (ZAP, Trivy, nmap, Dependency Check), так и с enterprise (Veracode, Checkmarx, Twistlock). Как правило, имеет некоторые сложности при интеграции с API.

Вот здесь можно увидеть пример скрипта для интеграции.

Secure code Box

Ссылка на Secure code box

Open-source фреймворк, объединяющий несколько бесплатных инструментов сканирования (ZAP, NMAP, Nikto, Arachni), собранных вместе в docker-compose в связке с Kibana и Elasticsearch. В отличие от того же DefectDojo, здесь все инструменты развертываются вместе с решением, и отчеты о результатах сканирования подтягиваются самостоятельно (не нужно писать скрипты для автоматической отправки issue в сборщик). Также можно запускать сканирование всех заявленных инструментов из UI. На текущий момент инструменты направлены исключительно на тестирование веб-приложений.

Несмотря на кажущуюся простоту развертывания и работы, разработчики заявляют, что это не one-button-click-solution и требуется глубокое понимание для настройки сканеров.

Archery

Ссылка на Archery

Еще одна open-source система управления уязвимостями. Есть поддержка Acuntetix, Nessus, Burp, Netsparker, WebInspect. В отличие от DefectDojo, о котором я упоминал ранее, решение позволяет запускать из консоли сканирование ZAP, Burp и OpenVAS. Из интересного то, что есть обработчик false positive. Ну и конечно же интеграция с CI/CD.

Еще материал по vulnerability management:

• Faraday

• VulnReport

• Сравнение инструментов

Public Cloud Security

Говоря про безопасный DevOps нельзя не сказать про безопасность облачных провайдеров (AWS, GCP, Azure, Oracle) в силу активного перехода из on-prem в облака.

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

AWS-inventor

Ссылка на AWS-inventor

Инструмент для инвентаризации активов AWS с помощью заданных параметров учетной записи AWS.

$ python aws_inventory.py# Select the generated JSON file when prompted$ firefox gui/dist/index.html

Aws-public-ips

Ссылка на AWS-puclic-ips

Инструмент для получении информации об общедоступных ресурсах AWS в виде ip-адресов.

# Uses default ~/.aws/credentials$ aws_public_ips -f json -s apigateway,cloudfront,ec2, \    elasticsearch,elb,elbv2,lightsail,rds,redshift# With a custom profile$ AWS_PROFILE=production aws_public_ips ...

CloudSploit

Ссылка на CloudSploit

Инструмент для compliance-проверок публичных облаков AWS, GCP, Azure, OCI. В частности, можно провести проверку на CIS и PCI DSS.

# Edit the index.js file with your AWS key and secret# Run a standard scan$ node index.js# Run a compliance scan$ node index.js --compliance=hipaa

AWS Security Benchmark

Ссылка на AWS Security Benchmark

Отдельный инструмент для проверки AWS на соответствие CIS Amazon Web Services Foundations Benchmark 1.1.

$ python aws-cis-foundation-benchmark-checklist.py

S3 Scan

Ссылка на S3 Scan

Инструмент, формирующий отчет обо всех S3-корзинах и установленных для них ролях.

$ python s3scan.py [-f <format>] [-p <profile>]

Примечание. Наверное, самая большая подборка инструментов по AWS Security:

My-arsenal-of-aws-security-tools

G-Scout

Ссылка на G-Scout

Инструмент, формирующий отчет о проблемах с безопасностью GCP.

# Permissions required on the projects: Viewer, Security Reviewer, Stackdriver Account Viewer$ python gscout.py --project-id <projectID>

ScoutSuite

Ссылка для ScoutSuite

Популярный инструмент для проведения аудита безопасности публичных облаков GCP, AWS, Oracle, Azure.

# GCP example# Using an user account$ python Scout.py --provider gcp --user-account --project-id <projectID>#Using a service account$ python Scout.py --provider gcp                                     \                  --service-account --key-file service_account.json  \                  --project-id <projectID>

И это еще не все?

Подборку продолжать можно еще долго, но я постарался привести все, что может стать отправной точкой в процессе выстраивания безопасности DevOps/SDLC. Тем не менее, это далеко не все практики. Я не коснулся также этапов фаззинга, управления секретами и процесса проверки манифестов IaC. И разумеется, правильно построенный процесс разработки не может существовать без организационных мер и налаженных отношений между командами разработки и безопасности. Здесь я могу порекомендовать познакомиться с моделями оценки BSIMM и OWASP SAMM.

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

RASP - практика, при которой инструмент безопасности интегрируется напрямую с сервером, отслеживая его работу (обращения к базе данных, файловые операции, сетевые запросы и тд.). Часто к этой практике относят инструменты класса Container Run-time Security (например Sysdig Falco). Вот также RASP для отслеживания работы веб-приложений:

• OpenRASP

IAST - практика, совмещающая принципы работы SAST и DAST:

• Contrast

Fuzzing - практика тестирования приложения, при которой на вход программе подаются данные, которые могут привести к неопределенному поведению :

• Awesome Fuzzing

IaC Security - практика тестирования декларативного описания инфраструктуры через конфигурационные файлы на соответствие требования безопасности:

• Cfn Nag-Сканер AWS CloudFormation шаблонов на небезопасную конфигурацию

• Checkov-Сканер Terraform, AWS CloudFormation и Kubernetes шаблонов на небезопасную конфигурацию

• Terrascan-Сканер Terraform шаблонов на соответствие лучшим практикам безопасности

• Tfsec-Сканер Terraform шаблонов на неправильную конфигурацию и несоответствие лучшим практикам безопасности AWS, Azure и GCP.

• Kubernetes YAML validating:

  • Kubeval

  • Kube-score

  • Config-lint

  • Copper

  • Conftest

  • Polaris

  • Сравнение инструментов

Compliance-as-code - практика представления требований безопасности через декларативное описание в виде кода с целью дальнейшей непрерывной оценки на соответствие:

• Chef InSpec

• Compliance Masonry

• OpenSCAP

Security Chaos Engineering - молодая практика, основанная на нескольких принципах: определение "стабильного" состояния, создание гипотезы о последующем состоянии, введение переменных, осуществление попыток "сломать" гипотезу. После серии тестов инфраструктура оценивается на предмет доступности, безопасности и производительности. Как итог цель всего этого - получить систему, способную выдерживать экстремальные условия. Security Chaos Engineering отличается от классического Chaos Engineering лишь гипотезами, касающимися безопасности. Тесты могут состоять, например, из отключения правил Security Groups, изменения файлов случайным образом, прослушивания портов, внедрения вредоносного трафика в VPC, случайного "убийства" процессов. При этом все это должно быть автоматизированно, а состояния системы должны непрерывно отслеживаться. Примеры инструментов:

• ChaoSlingr

• Security Monkey

• Kube-monkey

Каналы и чаты по DevSecOps и безопасности приложений:

• DevSecOps Wine - канал по DevSecOps от автора статьи

• CloudSec Wine - канал про Public Cloud Security от автора статьи

• Mobile AppSec World - канал о безопасности мобильных приложений

• DevSecOps русскоговорящее сообщество

Привет, Хабр!

Как-то раз в нашей работе встретилась необходимость провести интеграцию сканера безопасности Netsparker и службы каталогов Active Directory. В этой статье я поделюсь инструкцией о том, как можно это сделать и на что стоит обратить внимание при настройке.

Забегая вперед, стоит отметить, что аналогичные шаги помогут настроить интеграцию с AD не только Netsparker, но и иных приложений, которые не имеют собственных средств взаимодействия с Active Directory.

Netsparker это коммерческий динамический сканер веб-приложений, который позволяет обнаруживать большое количество уязвимостей в реальном времени и при этом располагает широким набором средств для интеграции с различными инструментами разработки и сборки. Это позволяет осуществлять поиск уязвимостей еще до того, как приложение выходит в производственную среду.
Подробнее: https://www.netsparker.com/

Keycloak решение с открытым кодом, которое способно выступать промежуточным звеном между приложением и сторонним аутентификационным сервисом. Это часто необходимо в случаях, если требования к аутентификации превосходят возможности приложения или имеющаяся инфраструктура позволяет сделать бесшовную аутентификацию между всеми используемыми сервисами (SSO).
Keycloak позволяет интегрировать ваши приложения с внешними системами аутентификации пользователей, может выступать в качестве посредника для использования social login сервисов и многое другое.
Подробнее: https://www.keycloak.org/

Проблема

По умолчанию в Netsparker есть несколько вариантов внедрения Single Sign-On: с Google Cloud, PingIdentity, Okta, Azure AD, ADFS, а также базовая интеграция при помощи SAML2.0.

В случаях, когда нет возможности использования вышеприведенных вариантов (например не разрешается применять ADFS, но тем не менее требуется интеграция с AD) можно использовать базовый вариант с SAML.

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

Общая схема выглядит так:

Существует как минимум два режима работы. В первом режиме база пользователей AD синхронизируется с базой пользователей Keycloak, и система аутентификации Keycloak используется для разрешения доступа пользователям в Netsparker. Во втором режиме Keycloak берет на себя непосредственно аутентификацию пользователя в AD без сохранения данных пользователей в своей базе. При этом, если необходимо, можно вести базу пользователей (например которых нет в AD) дополнительно и в Keycloak.

Для того чтобы аутентификация в Netsparker была возможна, необходимо чтобы именем пользователя являлся его email-адрес. Это связано с особенностями пользовательской базы данных Netsparker, где каждая учетная запись определяется ее email-адресом. Знание этой особенности нам потребуется дальше.

Приступим.

Экспорт конфигурации Netsparker SSO

Первый шаг. Чтобы включить Single Sign-On в Netsparker необходимо сделать следующее:

1. Войти в Netsparker под административным пользователем и открыть Settings Single Sign-On.

2. Поставить флажок Enable для включения поддержки SSO.
   (!) Опция Enforce to authenticate ... нужна для того, чтобы запретить пользователям без прав администратора вход напрямую в Netsparker с использованием пароля.
   Остальные поля мы заполним чуть позже данными из Keycloak.

   Экран настройки Netsparker SSO

   
   После включения функции SSO на странице входа в Netsparker появится дополнительная ссылка для доступа через внешний сервис.
   Вот так это будет выглядеть для неаутентифицированного пользователя:

   Экран входа в Netsparker для неаутентифицированного пользователя

3. Справа на закладке SAML скачиваем базовый XML с метаданными Netsparker.
   Этот XML содержит настройки SAML-клиента (в нашем случае им является Netsparker), которые понадобятся для конфигурирования Keycloak, например Client Identifier, SAML Service URL.

   Сохранение SAML мета-данных Netsparker

На данном этапе с Netsparker'ом всё. Переходим в Keycloak.

Конфигурация Keycloak

1. Заходим в панель администратора Keycloak и создаем новый Realm с названием, например, Netsparker.
   Realm это раздел, в котором будет храниться вся конфигурация, касающаяся конкретно нашего приложения (Netsparker), включая настройки синхронизации с AD, собственная база пользователей и т. п.

   Экран добавления Realm'а

2. Теперь необходимо в этом Realm прописать нашего клиента (Netsparker), который будет пользоваться услугами Keycloak.
   Переходим на закладку Clients, нажимаем Create, импортируем XML, который сохранили из Netsparker.

   Экран добавления клиента Keycloak

   Данные формы подгрузятся из файла, поэтому нажимаем Save.

3. В открывшемся экране настроек клиента сразу сохраняем себе в блокнот данные сертификата (закладка SAML Keys).

   Данные сертификата клиента Keycloak

4. Возвращаемся на закладку Settings и вносим следующие изменения:

   Client Signature Required ставим в положение OFF, т. к. Netsparker пока не передает данные о своем алгоритме подписи, и поэтому SAML-запрос получается некорректным.
   Valid Redirect URIs модифицируем URL и заменяем часть строки адреса ?spid на *. Это поле задает шаблон для адресов, на которые Keycloak разрешено осуществлять перенаправление браузера. Это сделано для того, чтобы злоумышленник не мог подставить адрес подконтрольного ему сервиса.

   Настройки клиента Keycloak

   
   Остальные параметры для тестовой интеграции пока можно не трогать. Мы к ним вернемся, когда будем конфигурировать авто-добавление пользователей.

5. Нажимаем Save и возвращаемся в Netsparker.

Конфигурация Netsparker

Теперь на стороне сканера добавляем данные о провайдере аутентификационных данных (сокращенно IdP), в нашем случае это Keycloak.

1. Донастроим то, что мы начали настраивать на первых шагах.
   Снова открываем страницу Netsparker Settings Single Sign-On и прописываем идентификатор IdP и URL для SAML-запросов.

   У Keycloak эти значения стандартные:
   IdP Identifier:
   https://<домен-где-установлен-Keycloak>/auth/realm/<наш-Realm>
   SAML Endpoint:
   https://<домен-где-установлен-Keycloak>>/auth/realms/<наш-Realm>/protocol/saml
   X.509 Certificate:
   Сертификат в base64, который мы сохранили из Keycloak.

   Настройка SSO в Netsparker

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

   При нажатии на Sign in via your Identity Provider открывается промежуточная форма ввода email пользователя из Netsparker, из которой уже осуществляется переход на форму входа Keycloak. Пользовательские данные, вводимые на этой форме либо проверяются в базе пользователей Keycloak, либо прокидываются дальше на AD (мы посмотрим оба варианта).

   После успешного входа в Keycloak нас должно перенаправить обратно в Netsparker уже в аутентифицированном состоянии.

   Процесс входа в Netsparker

   
   Но чтобы это произошло, надо сперва сконфигурировать пользователей.

Создание пользователей вручную

Netsparker

Для начала заведем тестового пользователя в Netsparker для проверки интеграции.

1. В Netsparker открываем Team New Team Member, заполняем поля Name, Email и проставляем какие-нибудь разрешения (те, что на снимке, выбраны просто для примера):

   Экран создания пользователей в Netsparker

2. Активируем пользователя, кликнув на код подтверждения на странице Invitations.

   Список "приглашенных" пользователей

3. На открывшейся странице вводим пароль для созданного пользователя и нажимаем Create an account.
   Этот пароль будет использоваться, только если пользователь решит войти в Netsparker не через SSO, а через обычную форму входа:

   Экран регистрации нового пользователя Netsparker

Keycloak

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

Исправим это:

1. Заходим в Keycloak Manage Users, нажимаем Add user, вводим данные пользователя и сохраняем:

   Экран добавления пользователя в Keycloak

   Здесь важно указать Username в виде email-адреса и поставить Email Verified в положение On, чтобы можно было бесшовно перейти от Keycloak к Netsparker.

2. После сохранения появляется страница деталей пользователя. На ней в закладке Credentials необходимо установить пароль этому пользователю. Он при необходимости может отличаться от пароля в Netsparker:

   Создание пароля для пользователя Keycloak

   Ставим Temporary в положение Off и устанавливаем пароль.

Промежуточная проверка интеграции

Теперь можем убедиться, что наша интеграция Netsparker+Keycloak работает:

1. Открываем страницу входа в Netsparker и выбираем Sign in via your Identity Provider.

2. Вводим почтовый адрес нашего тестового пользователя и попадаем на страницу входа в Keycloak.

3. Указываем аутентификационные данные созданного пользователя.

   Экран входа в Keycloak

4. Если всё прошло успешно, Keycloak перенаправит нас на главную страницу Netsparker под нашим тестовым пользователем.

   Перенаправление из Keycloak в NetsparkerОсновной экран сканера Netsparker

Промежуточный итог
Итак, на данный момент у нас есть возможность входить в Netsparker, вводя данные пользователя в Keycloak. Следующий шаг и реализация начальной цели связать аутентификацию Netsparker c аутентификацией на AD. При необходимости мы также можем синхронизировать базу данных пользователей Keycloak с базой Active Directory.

Дорога в AD

Теперь сделаем следующий шаг и настроим аутентификацию пользователей Active Directory через Keycloak по LDAP. Для этого нам потребуется функция User Federation.

1. Открываем Keycloak User Federation и в списке провайдеров выбираем ldap.

   Выбор провайдера аутентификации в Keycloak

2. Дальше настройка может отличаться в зависимости от конкретной структуры AD, но я опишу на базовом примере, что нам потребуется.

   В окне Add user federation provider заполняем поля:
   Vendor: Active Directory.
   Connection URL: путь к вашему серверу.
   Например ldap://172.16.2.23:389.
   Users DN: путь навигации к записям пользователя.
   Например CN=Users,DC=cx,DC=local.
   Bind DN: путь к записи администратора AD.
   Например cn=cxadmin,cn=users,dc=cx,dc=local.
   Bind Credential: пароль учетной записи администратора.
   Например ваш валидный пароль :)

   (!) Если мы хотим, чтобы данные из AD сперва синхронизировались в локальную базу Keycloak, ставим переключатель Import User в положение On.

   Опция импортирования пользователей

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

3. Дальше необходима небольшая манипуляция с данными из AD. Так как Netsparker требует в качестве имени пользователя его email-адрес (помните ремарку в начале?), нам надо убедиться, что во-первых из AD придут только пользователи с почтовым адресом и, во-вторых, что имя пользователя будет содержать этот адрес, а не иной параметр.

   Поэтому следующим шагом мы прописываем фильтр пользователей AD, который выберет только сущности каталога с email. Дальше мы явно укажем, какой атрибут у нас будет служить именем пользователя:

   Custom User LDAP Filter: (&(objectCategory=person)(mail=*)(objectClass=user)).
   Username LDAP attribute: mail.

   Сохраняем форму, и в итоге наш экран настройки должен выглядеть так:

   Сводная страница настроек LDAP провайдера

4. Теперь сделаем так, чтобы при синхронизации пользователей AD они автоматически получали email в качестве имени пользователя. Для этого открываем закладку Mappers:

   Настройка mapper'ов

   И в mapperе Username заменяем атрибут cn на mail.

   Настройка отображения email адреса на имя пользователя

5. Сохраняем настройки.

(!) Если мы настраивали синхронизацию базы Keycloak с AD, мы можем проверить эту настройку, нажав Synchronize all users. Если всё прошло успешно, то на вкладке Users у нас появятся наши пользователи из AD'a:)

Проверяем, что всё работает

Можем убедиться, что наша настройка верна, войдя под учётной записью из AD в Netsparker.

1. Проверяем, что в Netsparker есть пользователь с таким почтовым адресом (Manage Team). Какой у него пароль неважно, так как аутентификация будет происходить на стороне AD.

   Искомый пользователь Netsparker

2. Открываем страницу Netsparker SSO и вводим email-адрес пользователя AD.

   Промежуточный экран входа в Netsparker SSO

3. На странице входа Keycloak вводим данные пользователя AD с паролем.

   Экран входа в Keycloak

4. Нам должна открыться страница Netsparker для этого пользователя.

   Основной экран Netsparker для аутентифицированного AD-пользователя Alex

Настройка автоматического создания пользователей

Вручную заводить новых пользователей зачастую неудобно, поэтому в Netsparker есть возможность упростить заведение новых учётных записей, которая называется auto provisioning. С ее помощью устраняется необходимость вручную добавлять нового пользователя: если его нет в базе данных Netsparker, то такой пользователь будет создан автоматически при попытке входа с верными данными своей учётной записи AD.

Дальше нам будет необходимо сделать небольшие изменения в конфигурациях Keycloak и Netsparker. Так как auto provisioning требует, чтобы сессия инициировалась Identity Provider'ом, давайте его и настроим:

Keycloak

1. Открываем настройки нашего клиента Keycloak Clients наш клиент.

2. Нам потребуется внести изменения в три поля:
   Valid Redirect URIs (опционально): можно оставить как было, а можно ограничить перенаправление конкретным клиентом (который задаётся параметром spid). Для этого копируем из настроек SSO Netsparke'а полный URL SAML 2.0 Service URL.
   IDP Initiated SSO URL: необходимо задать URL, который мы хотим использовать для нашего конкретного клиента (Netsparker), чтобы явно указать, что должно использоваться SSO, вызываемое со стороны IdP. Например netsparker. После этого пользователи смогут входить конкретно в Netsparker, используя URL из подсказки.
   Assertion Consumer Service POST Binding URL: URL, куда Keycloak будет отправлять SAML-данные для входа в Netsparker. Указываем здесь SAML 2.0 Service URL из настроек Netsparker'a.

   Дополнительная настройка клиента Keycloak

3. Сохраняем настройки.

Настройка mappers

Чтобы Keycloak формировал SAML-запрос в виде, необходимом Netsparker'у, необходимо добавить в него несколько обязательных полей (FirstName и LastName). В этом нам поможет mapper, который автоматически назначит полям SAML соответствующие поля из пользовательской записи.

Для этого открываем Keycloak Clients Mappers и создаем mapper, нажав на Create.

Содержимое полей mapper задаем как на картинке ниже:

Аналогично создаём mapper для фамилии:

Итоговый список должен выглядеть так:

Netsparker

Последнее, что нам нужно сделать донастроить Netsparker, чтобы он создавал пользователей и принимал запросы на это действие от Keycloak.

1. Открываем Netsparker Settings Single Sign-On.

2. В поле SAML 2.0 Endpoint указываем URL из Keycloak из подсказки поля IDP Initiated SSO URL.

3. Выбираем опцию Enable Auto Provisioning и сохраняем настройки.

   Настройка автоматического создания пользователей в Netsparker

Финальная проверка

Теперь проверим как это всё работает.

1. Прежде всего теперь на странице Netsparker Team можем удалить пользователя AD, которого мы создавали вручную.

   Удаление пользователя

2. В Keycloak завершаем все сессии, чтобы они нам не мешали: Keycloak Manage Sessions Logout all.

3. Открываем страницу Keycloak для SSO (напомню, Target IDP initiated SSO URL это ссылка вида:
   https://yourdomain.com/auth/realms/netsparker/protocol/saml/clients/netsparker).

4. Вводим данные пользователя из AD.

5. Если всё прошло успешно, в Netsparker будет создан соответствующий пользователь с минимальными правами и для него будет установлена новая сессия.

   Основной экран Netsparker для пользователя, автоматически созданного при входе через AD

Что дальше?

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

Если была выбрана опция auto provisioning, необходимо от имени административного пользователя выдать необходимые разрешения созданному пользователю, чтобы тот мог работать с Netsparker.

Для простоты лучше первый раз для создания пользователя входить через Target IDP initiated SSO URL и уже впоследствии аутентифицироваться либо по этому же URL, либо осуществлять вход через привычную страницу Netsparker Login.

Еще один нюанс в данный момент выход пользователя из Netsparker не приводит к выходу пользователя из Keycloak. Поэтому, когда в следующий раз мы решим войти при помощи SSO, нас сразу перебросит в Netsparker под последним аутентифицированным пользователем. Это можно решить, например, уменьшив длительность сессии пользователя в Keycloak. Тогда его SSO-сессия будет автоматически уничтожена после указанного промежутка времени.
Настройка осуществляется в Realms Netsparker Tokens:

Также пользователь может вручную закончить свою сессию на собственной странице учётной записи Keycloak по ссылке вида: https://keycloak.yourcompany.com/auth/realms/netsparker/account
После этого для входа в Netsparker потребуется снова аутентифицироваться в Keycloak и можно будет осуществить вход под другим пользователем.

Заключение

Мы рассмотрели в деталях, как можно аутентифицировать пользователей Netsparker через Active Directory с использованием промежуточного решения Keycloak. В принципе, такой же процесс может быть применён и для других приложений, которые не работают с Active Directory напрямую, но поддерживают SAML для описания деталей аутентификации.
Keycloak позволяет достаточно гибко настраивать и дополнять систему аутентификации, комплексно закрывая этот аспект безопасности для приложений, используемых в организации.

В данной статье мы рассмотрим небезопасные варианты написания собственного Dockerfile, а также лучшие практики, включая работу с секретами и встраивание инструментов статического анализа. Тем не менее для написания безопасного Dockerfile наличия документа с лучшими практиками мало. В первую очередь требуется организовать культуру написания кода. К ней, например, относятся формализация и контроль процесса использования сторонних компонентов, организация собственных Software Bill-of-Materials (SBOM), выстраивание принципов при написании собственных базовых образов, согласованное использование безопасных функций, и так далее. В данном случае отправной точкой для организации процессов может служить модель оценки зрелости BSIMM. Однако в этой статьей пойдет речь именно о технических аспектах.

Безопасное написание Dockerfile

Задавать LABEL и не использовать тег latest

Использовать тег latest для базовых образов крайне нежелательно, так как это создает неопределенное поведение по мере того, как базовый образ будет обновляться. К тому же это не гарантирует, что последние версии базовых образов не будут уязвимы. Наиболее предпочтительный вариант можно увидеть на примере ниже:

FROM redis@sha256:3479bbcab384fa343b52743b933661335448f816LABEL version 1.0LABEL description "Test image for labels"

Для описания собственного образа также рекомендуется использовать инструкцию LABEL, чтобы исключить ошибку со стороны тех, кто будет использовать ваш образ в дальнейшем. Хорошей практикой также является определение LABEL securitytxt.

LABEL securitytxt="http://personeltest.ru/aways/www.example.com/.well-known/security.txt"

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

Не использовать автоматическое обновление компонентов

Использование apt-get upgrade,yum update может привести к тому, что внутри вашего контейнера будет произведена установка неизвестного вам ранее ПО, либо ПО уязвимой версии. Чтобы избежать этого, устанавливайте пакеты, четко указывая версию для каждого из них. Каждая версия должна проверяться на наличие в ней уязвимостей до того, как компонент окажется внутри вашего контейнера. Версия компонента может быть проверена с помощью инструментов класса Software Composition Analysis (SCA).

Пример установки компонента с точностью до версии:

RUN apt-get install cowsay=3.03+dfsg1-6

Производить скачивание пакетов безопасным образом

Использование curl и wget без мер предосторожности позволяет злоумышленнику выполнять скачивание нежелательных компонентов с неизвестных ресурсов (атака "человек-посередине", при которой злоумышленник может перехватить незащищенный трафик и подменить скачиваемый нами пакет на зловредный). Это полностью разрушает концепцию Zero trust, согласно которой необходимо проверять любое подключение или действие до предоставления доступа (или в данном случае установки компонента с неизвестного ресурса). Соответственно следующий сценарий скачивания будет являться грубейшей ошибкой, так как происходит выполнение скрипта, полученного из недоверенного источника по небезопасному каналу без должных проверок:

RUN wget http://somesite.com/some-packet/install.sh | sh

Чтобы убедиться, что скаченный компонент будет являться действительно тем, что мы ожидаем, в качестве решения может подойти использование GNU Privacy Guard (GPG). Разберемся, как это работает.

В большинстве случаев вендоры вместе с библиотекой или ПО предоставляют также хеш-сумму, которую мы можем проверить при скачивании. Данная хеш-сумма подписывается вендорами с помощью закрытого ключа в рамках GPG, а открытые ключи помещаются в репозитории. Следующий пример демонстрирует, как может выглядеть безопасное скачивание компонентов Node.js:

RUN gpg --keyserver pool.sks-keyservers.net \--recv-keys 7937DFD2AB06298B2293C3187D33FF9D0246406D \            114F43EE0176B71C7BC219DD50A3051F888C628DENV NODE_VERSION 0.10.38ENV NPM_VERSION 2.10.0RUN curl -SLO "http://nodejs.org/dist/v$NODE_VERSION/node-v \$NODE_VERSION-linux-x64.tar.gz" \&& curl -SLO "http://nodejs.org/dist/v$NODE_VERSION/\SHASUMS256.txt.asc" \&& gpg --verify SHASUMS256.txt.asc \&& grep " node-v$NODE_VERSION-linux-x64.tar.gz$" SHASUMS256.txt.asc | sha256sum -c -

Давайте разберемся, что здесь происходит:

1. Получение открытых GPG-ключей

2. Скачивание Node.js пакета

3. Скачивание хеш-суммы Node.js пакета на базе алгоритма SHA256

4. Использование GPG-клиента для проверки, что хеш-сумма подписана тем, кто владеет закрытыми ключами

5. Проверяем, что вычисленная хеш-сумма от пакета совпадает со скаченной с помощью sha256sum

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

Иногда разработчикам бывает необходимо использовать сторонние репозитории для установки компонента с помощью deb или rpm. В данном случае мы также можем воспользоваться GPG, а проверка хеш-суммы будет проводиться менеджерами пакетов при скачивании.

Пример безопасного добавления GPG-ключей вместе с источником пакетов.

RUN apt-key adv --keyserver hkp://pgp.mit.edu:80 \--recv-keys 573BFD6B3D8FBC641079A6ABABF5BD827BD9BF62RUN echo "deb http://nginx.org/packages/mainline/debian/\jessie nginx" >> /etc/apt/sources.list

В случае, если для пакетов цифровая подпись в явном виде не предоставляется вендором, ее необходимо предварительно создать и сравнить в рамках сборки.

Пример для SHA256:

RUN curl -sSL -o redis.tar.gz \http://download.redis.io/releases/redis-3.0.1.tar.gz \&& echo "0e21be5d7c5e6ab6adcbed257619897db59be9e1ded7ef6fd1582d0cdb5e5bb7 \*redis.tar.gz" | sha256sum -c -

Не использовать ADD

Инструкция ADD, получив в качестве параметра путь к архиву, автоматически распакует этот архив при своем выполнении. Это может привести, в свою очередь, к появлению zip-бомбы внутри контейнера. При распаковке zip-бомба может вызвать отказ в обслуживании (DoS) приложения, путем заполнения всего выделенного свободного места.

Еще одна небольшая особенность ADD команды заключается в том, что вы можете передать ей URL в качестве параметра, и она будет извлекать контент во время сборки, что также может привести к атаке "человек-посередине":

ADD https://cloudberry.engineering/absolutely-trust-me.tar.gz

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

Задавать USER в конце Dockerfile

В случае, если злоумышленнику удастся заполучить shell внутри вашего контейнера, он может оказаться root'ом, что сильно упростит дальнейшую атаку с выходом за пределы контейнера. Чтобы избежать этого, указывайте пользователя в явном виде через инструкцию USER. Однако это работает только в том случае, если вашему приложению не требуется привилегии root после сборки.

RUN groupadd -r user_grp && useradd -r -g user_grp userUSER user

Использовать gosu вместо sudo в процессе инициализации

Утилита gosu будет полезна, когда необходимо предоставлять root доступ после сборки Dockerfile во время инициализации, но при этом приложение должно запускаться в непривилегированном режиме.

В примере ниже выполняется команда chown в рамках entrypoint-скрипта, требующая права root, после чего приложение продолжает выполняться из-под пользователя redis.

#!/bin/bashset -eif [ "$1" = 'redis-server' ];  then    chown -R redis .     exec gosu redis "$@"  fiexec "$@"

Основная цель инструмента - запуск процессов от определенного пользователя, но в отличие от sudo и su, gosu не делает fork процессов, как показано ниже:

$ docker run -it --rm ubuntu:trusty su -c 'exec ps aux'USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMANDroot         1  0.0  0.0  46636  2688 ?        Ss+  02:22   0:00 su -c exec ps aroot         6  0.0  0.0  15576  2220 ?        Rs   02:22   0:00 ps aux$ docker run -it --rm ubuntu:trusty sudo ps auxUSER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMANDroot         1  3.0  0.0  46020  3144 ?        Ss+  02:22   0:00 sudo ps auxroot         7  0.0  0.0  15576  2172 ?        R+   02:22   0:00 ps aux$ docker run -it --rm -v $PWD/gosu-amd64:/usr/local/bin/gosu:ro ubuntu:trusty gosu root ps auxUSER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMANDroot         1  0.0  0.0   7140   768 ?        Rs+  02:22   0:00 ps aux

Это сохраняет концепцию, согласно которой контейнер ассоциируется с единственным процессом. Тем не менее, из слов разработчиков gosu не является заменой sudo, так как в рамках данного fork'а происходит взаимодействие с Linux PAM через функции pam_open_session() и pam_close_session(). Использование gosu вместо sudo за пределами процесса инициализации может привести к некорректной работе приложения.

Distroless images и минимальные образы

Можно сильно сократить поверхность атаки злоумышленника отказавшись от базовых образов Linux-дистрибутивов (Ubuntu, Debian, Alpine) и перейдя на Disroless-образы. Это образы, которые содержат только само приложение и необходимые для него зависимости без использования лишних системных компонентов (например, bash). Одним из явных преимуществ, помимо сокращения поверхности атаки и возможностей злоумышленника, является снижение размера образа. Это в свою очередь уменьшает "шум" в результатах сканирования такими инструментами как Trivy, Clair и так далее.

Подобная стратегия имеет много преимуществ с точки зрения безопасности, но сильно затрудняет работу разработчиков, которым необходимо заниматься отладкой внутри контейнера. Альтернативным вариантом может являться использование минимального образа, например, на базе UNIX-сборки Alpine. При ответственном соблюдении данного подхода, образ разработчика будет содержать минимум зависимостей, что позволит сканерам образов сформировать меньший объем результатов, среди которых будет проще отсеять ложные срабатывания.

Цикл статей по созданию минимального образа:

• The Quest for Minimal Docker Images, part 1

• The Quest for Minimal Docker Images, part 2

• The Quest for Minimal Docker Images, part 3

Одним из вариантов, как можно эффективно сократить размер образа является multi-stage сборка, которая ко всему прочему поможет безопасно работать с секретами. Об этом будет в следующем подразделе.

Полезным инструментом также является Docker-slim, позволяющий уменьшить размер написанного образа.

Безопасная работа с секретами

Секреты могут по ошибке помещаться в качестве параметра инструкции ENV или передаваться внутрь образа как текстовый файл. Также секреты могут скачиваться через wget. Подобные сценарии недопустимы, так как злоумышленник может с легкостью получить доступ к секретам. Это можно сделать, например, получив доступ к API Docker:

# docker inspect ubuntu -f {{json .Config.Env}}["SECRET=mypassword", ...]

Также злоумышленник может получить доступ к секретам через логи, директорию /proc или при утечки файлов исходных кодов. В данном случае лучше всего может подойти использование решений класса Vault, например, HashiCorp Vault или Conjur, однако рассмотрим и другие методы.

Соблюдать принцип многоэтапных сборок

Многоэтапная (multi-stage) сборка поможет не только сократить размер вашего образа, но еще и организовать эффективное управление секретами. Основной принцип - извлекать и управлять секретами на промежуточном этапе сборки образа, который позже удалится. В итоге конфиденциальные данные не попадут в сборку конечного образа.

#builderFROM ubuntu as intermediateWORKDIR /appCOPY secret/key /tmp/RUN scp -i /tmp/key build@acme/files .#runnerFROM ubuntuWORKDIR /appCOPY --from=intermediate /app .

Один из минусов этого сценария - сложное кэширование, что ведет к замедлению сборки.

Работа с секретами через BuildKit

С версии Docker 18.09 появляется экспериментальная интеграция со сборщиком BuildKit, которая позволит кроме увеличения производительности, эффективно работать с секретами.

Пример синтаксиса:

# syntax = docker/dockerfile:1.0-experimentalFROM alpine# shows secret from default secret locationRUN --mount=type=secret,id=mysecret cat /run/secrets/mysecre# shows secret from custom secret locationRUN --mount=type=secret,id=mysecret,dst=/foobar cat /foobar

После выполнения сборки с помощью buildkit с указанием ключа --secret секретная информация не сохранится в конечном образе.

Пример:

$ docker build --no-cache --progress=plain --secret id=mysecret,src=mysecret.txt .

Подробнее можно прочитать в официальной документации Docker.

Остерегаться рекурсивного копирования

Команда из примера ниже может привести к тому, что файл секрета случайно окажется внутри вашего образа, если находится внутри той же директории. Если вы имеете подобные файлы, не забывайте использовать .dockerignore. Среди файлов внутри образа могут оказаться .git, .aws, .env.

COPY . .

Один из примеров подобных ошибок - кейс с утечкой исходных кодов Twitter Vine. Так в 2016 году специалист по информационной безопасности обнаружил на DockerHub образ vinewww, внутри которого обнаружились исходные коды сервиса Vine, ключи API и секреты сторонних сервисов.

Анализаторы Dockerfile

Используйте анализаторы Dockerfile, которые можно встроить в ваш пайплайн сборки. Это могут быть:

• Hadolint

• Conftest

Hadolint - простой линтер Dockerfile. Большая часть проверок не относится к security и основана на официальных рекомендациях Docker (ссылка). Однако для наиболее распространенных ошибок таких проверок будет достаточно.

Conftest - анализатор файлов конфигураций, в том числе Dockerfile. Для проверки Dockerfile требуется предварительно написать правила на языке Rego, который, помимо этого, используется в быстро набирающей технологии Open Policy Agent для защиты облачных сред в процессе эксплуатации. Это позволит сохранить вариативность, возможность кастомизации и не потребует изучения ранее неизвестных языков. Conftest не содержит встроенный набор правил, поэтому подразумевается, что вы будете писать их самостоятельно. В качестве отправной точки можно использовать эту статью.

Для автоматизации процесса проверки можно встроить эти инструменты в пайплайн разработки. Пример встраивания:

Способы и примеры внедрения утилит для проверки безопасности Docker.

Практика

Вы можете попробовать проэксплуатировать распространенные уязвимости при написании Dockerfile с помощью образа Pentest-in-Docker. Пошаговое описание можно найти в репозитории. Одна из главных ошибок - использование debian:wheazy, старого образа Debian, на котором поддерживается не требующийся для работы приложения Bash, содержащий в себе уязвимость удаленного выполнения кода (RCE). Таким образом злоумышленник может получить доступ к сервисной учетной записи www-data, отправив запрос на подключение к reverse-shell. Вторая ошибка - использование sudo, что позволяет злоумышленнику повысить привилегии от www-data до root внутри контейнера. И наконец отсутствие USER в конце Dockerfile из-за чего злоумышленник может выполнять действия из-под root в случае, если получит доступ к API Docker.

Дополнительные ресурсы

• DevSecOps Wine - канал про выстраивание безопасности разработки

• DevSecOps Chat - чат, где обсуждают процессы DevSecOps

• AppSec Chat - чат, где обсуждают вопросы безопасности приложений

• Docker Security Best Practices from the Dockerfile

• 10 Docker Security Best Practices

• Docker Security. Using Containers Safely in Production

• Liz Rice. Container Security: Fundamental Technology Concepts that Protect Containerized Applications.

Привет Хабр!

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

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

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

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

Содержание

1. Что такое CodeQL
2. Сценарии использования CodeQL
3. Демонстрация работы
4. Консоль LGTM
5. Установка CodeQL
6. Кодовая база
7. Как выглядит простой CodeQL запрос
8. Что дальше?
9. Дополнительные материалы

Что такое CodeQL

CodeQL это open-source инструмент и язык запросов, немного напоминающий SQL и позволяющий программным образом обращаться к тем или иным участкам кода и выполнять заданные аналитиками проверки графа потоков данных/управления и структуры исходного кода в целом. Аналогом этому подходу являются конфигурируемые правила поиска уязвимостей в инструментах SAST (Static Application Security Testing).

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

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

Изначально CodeQL это разработка компании Semmle, которая в сентябре 2020 была куплена GitHub и внедрена в их Security Lab. С этого момента развитием продукта занимается сам GitHub и небольшое сообщество энтузиастов. На данный момент официальный репозиторий содержит суммарно свыше 2000 QL-запросов, которые покрывают большое количество разнообразных проблем с кодом, начиная от поиска некорректных регулярных выражений в JavaScript и заканчивая обнаружением использования небезопасных криптографических алгоритмов в коде на C++.

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

На данный момент с разной степенью полноты поддерживаются следующие языки: C/C++, C#, Java, Go, Python, JavaScript/TypeScript. Помимо этого для каждого языка есть набор поддерживаемых фреймворков, упрощающий написание запросов.

CodeQL предоставляется в нескольких вариантах:

1. Консольная утилита, позволяющая встроить проверки в CI/CD цикл и осуществлять сканирование кода из командной строки.

2. Расширение для Visual Studio Code для удобного написания и ad-hoc исполнения запросов.

3. Онлайн-консоль LGTM, позволяющая писать запросы и проводить тестовое сканирование приложения из заданного GitHub-репозитория.

Кроме этого можно подключить сканирование своих репозиториев непосредственно в CI/CD на GitHub.

Всё ещё не убеждены попробовать? Тогда подкину дополнительную мотивацию. GitHub проводит соревнования CTF и вознаграждаемые bug bounty программы для энтузиастов, которые предлагают новые запросы, помогающие обнаруживать как уже известные и документированные уязвимости (CVE), так и 0-day уязвимости.

Сценарии использования CodeQL

Давайте посмотрим, какие есть потенциальные варианты использования CodeQL в нашем проекте:

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

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

3. Самый продуктивный сценарий включает в себя модификацию базовых запросов и/или написание собственных новых запросов, исходя из специфики конкретного приложения и появляющихся угроз.
   Например при выходе очередной 0-day уязвимости аналитик безопасности может составить запрос, который будет проверять все проекты на ее наличие. Или при анализе дефектов, найденных в процессе внутреннего аудита, каждый такой дефект может быть переписан на языке QL, чтобы не допустить проблем в других проектах.

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

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

Демонстрация работы

Впрочем давайте сразу посмотрим, как выглядит синтаксис запроса и результат работы CodeQL на примере запроса в консоли LGTM.

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

Или более сложный случай, когда мы ищем проблемы с Cross-Site Scripting:

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

А вот так тот же результат выглядит в расширении для VSCode:

На приведенном скриншоте мы видим инструкции CodeQL (верхняя панель), которые отслеживают путь данных от удалённых точек ввода пользовательских данных (например параметры GET-запросов) до конструкций кода, способных отобразить эти недоверенные данные пользователю. При этом отдельной инструкцией isSanitizer указывается, что в коде присутствует санитизирующая функция и соответственно если поток подозрительных данных проходит через эту функцию, он не должен дальше восприниматься как недоверенный. Это один из нескольких способов, которыми мы можем уменьшить количество заведомо ложных срабатываний.

В свою очередь, в результатах выполнения запроса (нижняя панель) мы можем посмотреть участок кода, где в приложении появляются недоверенные данные (т. н. source) и участок кода, где они выводятся (т. н. sink).

Консоль LGTM

Чтобы поэкспериментировать с языком без локальной установки пакета CodeQL можно воспользоваться онлайн-консолью LGTM (Looks Good To Me). Она включает в себя простой редактор запросов и возможность выполнить этот запрос на уже предустановленных кодовых базах нескольких open-source проектов, либо на своем GitHub-проекте.

Давайте сразу попробуем исполнить простейшие запросы и начать практическое знакомство с CodeQL:

1. Переходим в онлайн-консоль: https://lgtm.com/query/.

2. Выбираем в качестве языка JavaScript, а в качестве проекта meteor/meteor.

3. Копируем нижеприведенные запросы.

4. Нажимаем Run и смотрим результаты в панели под полем ввода кода.

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

import javascriptfrom ClassExpr ceselect ce

Более сложный запрос, который покажет нам все места в файле client.js, где происходит вызов функции eval(), а также аргументы этой функции:

import javascriptfrom CallExpr callwhere call.getCalleeName() = "eval" and call.getLocation().getFile().getRelativePath().matches("%client.js")select call, call.getAnArgument()

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

Установка CodeQL

Для использования в своих проектах на постоянной основе консоль LGTM не очень удобна, поэтому есть смысл установить CodeQL CLI и библиотеки локально.

Процесс установки всего пакета в целом несложен, но требует понимания ряда нюансов.

Простой вариант, с которого можно начать, выглядит так:

1. Установить VSCode и CodeQL extension.

2. Скачать и распаковать CodeQL CLI в директорию, например, codeql.

3. Прописать путь до директории codeql в %PATH%.

4. Скачать стартовый воркспейс VSCode для работы с CodeQL (впоследствии можно будет сделать свой, но для начала работы можно использовать готовый):
   git clone https://github.com/github/vscode-codeql-starter/

   git submodule update --init --remote

   В нем мы будем работать (то есть писать наши запросы) в папке, соответствующей интересующему нас языку (например для JS это codeql-custom-queries-javascript).

5. Скачиваем тестовую кодовую базу (то есть базу, в которой определенным образом хранятся все необходимые данные о коде и внутренних взаимосвязях в нем, о чем подробнее будет рассказано ниже), например (для JS) https://github.com/githubsatelliteworkshops/codeql/releases/download/v1.0/esbenabootstrap-pre-27047javascript.zip
   Чуть ниже мы посмотрим как создавать свои собственные кодовые базы для наших проектов.

6. Опционально распаковываем архив с кодовой базой.

7. В VSCode выбираем Open workspace и открываем файл стартового воркспейса.

8. В VSCode на закладке CodeQL добавляем папку (или архив) с кодовой базой, против которой будет запускаться анализ кода.

9. Готово. Теперь в соответствующей папке воркспейса (см. шаг 4) можно открыть файл example.ql и в нем начать писать свои запросы.

10. Исполняем тестовый запрос и убеждаемся, что всё работает

import javascriptfrom Expr eselect Wazzup!

Кодовая база

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

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

Для разных языков процесс создания базы немного отличается. Например создание кодовой базы для JS в папке my-js-codebase выполняется следующей командой в директории, которая содержит исходный код:

codeql database create my-js-codebase --language=javascript

Для компилируемых языков требуется, чтобы в системе был соответствующий компилятор и сборщик (например Maven для Java)

Следующий шаг загрузить информацию о базе в VSCode. Это делается в редакторе на соответствующей вкладке CodeQL Choose Database from Folder

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

Как выглядит простой CodeQL запрос

Давайте разберем, из чего вообще состоит типичный запрос в CodeQL на примере кодовой базы на языке JavaScript.

Самый базовый запрос, который выводит все jQuery-функции с именем $ (типа $(arg1, arg2)) и их первый аргумент, выглядит так, как показано ниже. Вы можете самостоятельно выполнить его для любой кодовой базы с jQuery:

/*** @name QueryName* @kind problem* @id my_id_1*/// метаданныеimport javascript // Выражение для подключения библиотеки CodeQL для работы с конструкциями JavaScript.// Также есть возможность подключения других библиотек для работы с различными фреймворками и технологиями.// Например semmle.javascript.NodeJS или semmle.javascript.frameworks.HTTP.from CallExpr dollarCall, Expr dollarArg // Объявление переменной dollarCall типа CallExpr и переменной dollarArg типа Expr.// CallExpr - это класс из стандартной библиотеки, представляющий коллекцию всех вызовов функций в интересующем нас коде.// Expr - класс, представляющий коллекцию всех выражений. Например в Object.entries = function(obj) выражениями являются //   вся строка целиком, Object, Object.entries, entries, function(obj), obj.where dollarCall.getCalleeName() = "$"// Логические формулы, которые мы применяем к объявленным переменным.// Мы проверяем, что результат выполнения предиката (т.е. логической инструкции) getCaleeName() (который возвращает название // вызываемой функции) нашего объекта dollarCall (который содержит все вызовы функций) равен "$"and dollarArg = dollarCall.getArgument(0)// Эта логическая формула операцией AND соединяется с предыдущей и уточняет условие, применяемое в запросе.// В итоге мы из всех вызовов функций, в названии которых есть $ выбираем в переменную //  dollarArg первые аргументы (как сущности, а не как конкретные значения аргументов).select dollarCall, dollarArg // указание на то, какие выражения (значение каких переменных или предикатов) мы хотим вывести в результате.

Как вы можете заметить, синтаксис языка схож с синтаксисом SQL, но при этом в основе лежат концепции ООП. В последующих частях мы познакомимся чуть поглубже с нюансами, терминами и идеями, которые лежат в основе CodeQL.

Что дальше?

В этой вводной статье мы немного прикоснулись к тому, что такое CodeQL и чем он может быть нам полезен, как начать с ним работать и начать создавать свои первые запросы.

Рекомендую поэкспериментировать с запросами на разных приложениях (либо собственных, либо open-source) хотя бы в онлайн-консоли LGTM.

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

https://lab.github.com/githubtraining/codeql-u-boot-challenge-(cc++) интерактивный курс по работе с CodeQL на примере C/C++

https://lab.github.com/githubtraining/codeql-for-javascript:-unsafe-jquery-plugin интерактивный курс по анализу JavaScript Bootstrap с помощью CodeQL.

Плюс к этому для начала подойдет очень полезный двухчасовой мастер-класс от GitHub, на котором рассматривается база CodeQL и где при помощи лектора зритель учится шаг за шагом писать запрос для поиска небезопасной десериализации в коде Java-приложения (фреймворк XStream):

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

It is dangerous to go alone! CodeQL инструмент достаточно сложный, с большим количеством нюансов и, к сожалению, с пока еще не очень большой экспертизой в мире. Поэтому мы бы хотели уже сейчас заняться развитием русскоязычного сообщества экспертов в CodeQL для обмена опытом и совместного решения проблем (которые, разумеется, тоже существуют). Для этой цели мы создали отдельный канал в Telegram, посвященный обсуждениям нюансов этого инструмента и расширению круга экспертизы. Там же мы публикуем новости, обучающие материалы и другую информацию по CodeQL.

Присоединяйтесь - https://t.me/codeql !

Дополнительные материалы

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

https://help.semmle.com/codeql/ общая помощь по CodeQL от изначальных разработчиков.
https://help.semmle.com/QL/ql-handbook/ референс по синтаксису языка.
https://help.semmle.com/QL/learn-ql/ детальная помощь по CodeQL для разных языков.
https://securitylab.github.com/get-involved информация по тому, как можно узнать больше про CodeQL, помочь его развитию, а также по тому, как получить инвайт в Slack-канал (англоязычный) с ведущими экспертами со всего мира и разработчиками самого CodeQL.

Привет, Хабр!

В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. Secure SDLC или Secure software development life cycle). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.

Этой статьёй я хочу начать цикл, освещающий процессы безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. Моя задача последовательно, фундаментально и лаконично изложить этот фреймворк, чтобы уменьшить порог вхождения в предмет. Материал предназначен для разработчиков, менеджеров, методологов и других людей, которые в силу обстоятельств, вынуждены погружаться в безопасную разработку в контексте ОУД и требований Банка России. В подготовке материала мне помогал независимый эксперт и специалист по информационной безопасности - Рустам Гусейнов.

Подробнее под катом

Оглавление

1. Введение и цели цикла

2. История и эволюция фреймворка

3. Центральный банк как популяризатор ОУД4

4. Общие положения и концепции ОУД4

5. Заключение

6. Полезные ссылки и материалы

7. Приложение (список сокращений)

Введение и цели цикла

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

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

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

История и эволюция фреймворка

ОУД расшифровывается как оценочный уровень доверия. Из самого названия следует цель фреймворка гарантировать соответствие продукта определенным критериям, заявленным в соответствующих стандартах, чтобы пользователи (заказчики, владельцы, физические лица и т.д.) могли доверять программному или аппаратному обеспечению, прошедшему необходимые проверки и декларирующему через них соответствие необходимым требованиям. Чтобы не уходить в длинную лекцию о разработке, уязвимостях, их эксплуатации и сопутствующих рисках, напомним, что любая ИТ-система теоретически (а на деле чаще всего и практически были бы ресурсы!) несовершенна. Поэтому в силу различных недостатков, связанных с:

- архитектурой (дизайном);

- разработкой (кодированием архитектуры в конечный продукт);

- внедрением (настройкой);

- эксплуатацией (обслуживанием).

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

Рисунок 1. Иллюстрация вектора атаки

Корни фреймворка уходят в становление индустрии ИБ в США в семидесятых и восьмидесятых годах прошлого века. По мере автоматизации и развития системного подхода силовые ведомства стремились гарантировать надежность системных компонентов, используемых государственными структурами для защиты информации. В течение какого-то времени несколько подобных стандартов существовали в различных юрисдикциях параллельно, пока не были объединены международными организациями ISO/IEC в новый, единый фреймворк ISO/IEC 15408 Common Criteria for Information Technology Security Evaluation (или просто Common Criteria то есть Общие Критерии). Любопытные до истории и фактов могут изучить подробности хроники по ссылкам внизу статьи, нас же интересует тот факт, что отечественные стандартизаторы с 2012 года начали анализировать и перерабатывать указанное семейство стандартов, чтобы издать их официально на русском под эгидой Стандартинформа.

Здесь стоит сделать небольшое отступление про статус подобных стандартов. На фоне вступления России в ВТО и либерализации законодательства национальные стандарты перестали быть обязательными на территории Российской Федерации. Сегодня, в соответствии со ст. 27Федерального закона 162-ФЗ О стандартизации, ГОСТы на территории России являются обязательными тогда, когда на них явно ссылаются какие-то нормативно-правовые акты уполномоченных органов государственной власти. Здесь на сцену выходит Центральный Банк России.

Рисунок 2. Титульный лист ГОСТ Р 15408-1-2012

Центральный банк как популяризатор ОУД4

Примерно в то время, когда Стандартинформ публикует первые документы семейства ГОСТ 15408, Банк России, в соответствии с международными трендами, начинает ужесточать требования к информационной безопасности платежей и кредитных организаций. Его целью является обеспечение устойчивости и надежности платежной и банковской системы, в том числе борьба с мошенничеством и несанкционированными переводами. Летом 2012 года принимается знаменитое положение 382-П, которое на следующие 8 лет становится основным нормативом по информационной безопасности для организаций, занимающихся денежными переводами на территории РФ (не считая более нишевых и специфичных требований, вроде стандарта PCI DSS, которые существовали и до этого).

С положения 382-П начинается внедрение ОУД 4 в жизнь финансовых организаций. В мае 2018 года Банк России, сталкиваясь с фактами печальной статистики уязвимостей ДБО и иных публично доступных интерфейсов взаимодействия с клиентами, вносит изменения в упомянутое Положение. Среди них содержится п. 2.5.5.1, цитата:

необходимо обеспечить: использование для осуществления переводов денежных средств прикладного программного обеспечения автоматизированных систем и приложений, сертифицированных в системе сертификации Федеральной службы по техническому и экспортному контролю на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей, в соответствии с законодательством Российской Федерации или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 .

В последующие годы это требование, в уточненном и видоизмененном виде, появлялось в других нормативах ЦБ, и по состоянию на 2021 год прямо или косвенно вытекает из:

- 672-П (через ссылку на ГОСТ Р 57580.1-2017, где в требованиях ЖЦ.8 и ЖЦ.20 косвенно формулируется ежегодный ОУД4);

- 683-П;

- 684-П;

- 719-П.

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

1. ПО распространяется клиентам организации (физическим или юридическим лицам);

2. ПО доступно через интернет неограниченному кругу лиц (а не закрыто VPN или иными ограничителями).

Рисунок 3. Границы применимости ОУД для приложений финансовых организаций

Рассмотрим, для примера, как эта логика работает для банков. Из п. 4.1 Положения 683-П, которое устанавливает требования к ИБ кредитных организаций, вытекает необходимость работ по ОУД для ПО распространяемого кредитной организацией клиентам для совершения действий в целях осуществления банковских операций, а также {ПО}, обрабатывающего информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием {} Интернет . В информационном письме Банка России от 8 июля 2020 г. N ИН-014-56/110, посвященном ОУД, приведена ссылка на Профиль Защиты Прикладного ПО, как на методику проведения анализа уязвимостей (подробнее об этом документе поговорим ниже). В свою очередь в п. 2.3.1 упомянутого Профиля развернуто сформулированы критерии подпадания прикладного ПО под работы в соответствии с ОУД4: клиентское ПО и/или выход в интернет. В упомянутой цитате из профиля находим:

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

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

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

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

Таким образом, спор о границах применимости ОУД был разрешен, а широкая формулировка границ применимости, проистекающая из 382-П уйдет в небытие вместе с указанным положением (оно утрачивает силу 01 января 2022 года на основании положения Банка России 719-П). Остается единственный вопрос как быть, если несколько приложений подпадают под требования? Наш ответ неоригинален риск-ориентированный подход и приоритизация проектов по ОУД внутри организации, особенно в условиях жестко лимитированного бюджета. Такую приоритизацию можно выстраивать на основании масштаба финансовых переводов, с учетом количества обрабатываемых персональных данных или исходить из других, менее очевидных соображений, например возможностей команды разработки оказывать поддержку проекту. В любом случае у вас наверняка есть более критичные каналы взаимодействия с клиентами и есть менее критичные. Если бюджет проекта ограничен, а количество различных приложений подпадающих под ОУД велико, самый простой критерий принятия решения - финансовый.

Теперь, когда мы изучили контекст вопроса, определились с границами применимости требований, решили в какой последовательности мы будем прогонять наши продукты через горнило ОУД, давайте поговорим о ключевых особенностях фреймворка и сделаем его обзор.

Общие положения и концепции ОУД4

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

Ключевыми документами, для понимания фреймворка, являются упомянутые в ссылках ГОСТы, которые не только вводят терминологию, но и содержат многочисленные разъяснения и примеры его различных аспектов. Ниже перечень, на наш взгляд, наиболее интересных и полезных:

1. ГОСТ 15408-1-2012

2. ГОСТ 15408-2-2013;

3. ГОСТ 15408-3-2013;

4. ГОСТ 18045-2013;

5. ГОСТ 57628-2017;

6. ГОСТ Р 58143-2018.

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

Рис 4. Управление конфигурацией и жизненный цикл продукта (согласно ГОСТ Р 15408-1-2012)

Этапы работ, формирующих ОУД, описываются в третьей части стандарта ГОСТ 15408, как показано на следующем рисунке.

Рис 5. Компоненты, формирующие ОУД

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

1. Ключевых концепций и ролей;

2. Базовых процессов (взаимодействий) и их результатов.

На базовом уровне можно выделить три ключевые роли:

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

Б. Разработчик, который создает этот продукт и выстраивает его жизненный цикл, в соответствии с требованиями Заказчика;

В. Оценщик, который проверяет соответствие разработанного продукта установленным требованиям.

Здесь нужно сделать оговорку, что несмотря на методологическую рекомендацию разделять описанные выше роли между субъектами во избежании конфликта интересов (например, чтобы не проверять самих себя, а привлекать третью, независимую сторону), на практике, в некоторых случаях, такое совмещение ролей допустимо и легально. Например, в последнем абзаце п. 9 Положения 684-П сказано, что анализ уязвимостей по требованиям к ОУД4 может проводиться некредитными финансовыми организациями самостоятельно, без привлечения третьей стороны (для сравнения в текущей редакции 683-П такого пункта нет, и подобные работы необходимо осуществлять с привлечением сторонней организации лицензиата ФСТЭК).

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

Какие же процессы и взаимодействия возникают в ходе работ в соответствии с фреймворком ОУД? Практически каждый процесс ИБ начинается с описания границ проекта и требований, безопасная разработка не исключение.

В общих чертах фреймворк декларирует следующую последовательность действий:

1. Разработать документацию и политики на продукт, которые регламентируют требования к ИБ приложения и разработки;

2. Обеспечить практическое применение документов в разработке конкретного продукта;

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

Ключевым элементом фреймворка является объект оценки (или ОО, например, ДБО, или какой-то компонент внутри ДБО), к которому предъявляются функциональные требования к безопасности (или ФТБ, например, необходимая реализация системы управления доступом или стойкая криптография), формулируемые в задании по безопасности или профиле защиты (разница между двумя в том, что задание по безопасности обычно создается Заказчиком самостоятельно, под себя; а профиль тиражируется различными институциями как минимально-адекватный стандарт для какого-то класса решений, например для межсетевых экранов или антивирусов). Так как объект оценки существует не в вакууме, а актуальные уязвимости связаны не только с разработкой и проектированием, но и с настройкой и эксплуатацией объекта, важными понятиями являются среда функционирования и конфигурация среды/объекта оценки. Наконец, сам оценочный уровень доверия представляет собой гамбургер из большего или меньшего набора компонент, в зависимости от выбранного уровня (смотри рисунок 5 выше).

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

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

1. С помощью сертификации (делается специализированными лабораториями, включенными в систему ФСТЭК);

2. С помощью оценки соответствия или анализа уязвимостей (делается самостоятельно для себя, либо сторонней организацией с лицензией ФСТЭК на ТЗКИ).

Это разделение нашло свое отражение в упомянутых по тексту положениях Банка России. В порядке убывания сложности и цены указанные сценарии можно разместить следующим образом:

1. Сертификация;

2. Оценка соответствия;

3. Анализ уязвимостей.

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

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

1. Описание архитектуры безопасности;

2. Функциональные спецификации;

3. Руководство пользователя по эксплуатации;

4. Представление реализации;

5. Проект объекта оценки;

6. Задание по безопасности.

Для начала такого состава документов нам хватит. Что же касается качества реализации фреймворка и надежности заключений Оценщика, то независимо от выбранного сценария работ, это во многом зависит от соблюдения Заказчиком и Разработчиком установленных семейством 15408 пререквизитов. От выстроенного в организации SDLC и наличия проработанной документации на конкретный продукт. Здесь действует правило аналогичное любому типу анализа защищенности чем более прозрачным для проверяющих будет ПО, чем полнее окажутся его описания, чем более компетентным и проактивным будет Заказчик, тем больше недостатков и уязвимостей смогут найти проверяющие и тем качественнее окажутся их заключения. Увы, в реальной жизни, в силу дороговизны работ и сложности процесса, указанные выше пререквизиты часто либо отсутствуют, либо находятся в зачаточном состоянии.

Заключение

Это наш первый опыт популярного изложения вопросов комплаенса (или соответствия стандартам) для широкой публики и нам важно получить обратную связь, чтобы адаптировать будущие тексты под интересы читателей и сделать их полезнее. Расскажите, пожалуйста, в комментариях - что вам понравилось в первой статье цикла, а что нет? Какие специфические темы, вопросы или примеры из жизни вы бы хотели подробно разобрать в контексте темы цикла? А может быть вы уже активно работаете с ОУД и хотите поделиться решенными проблемами, замечаниями и наблюдениями? Помимо упомянутой во введении методички по вопросам ОУД, мы планируем серию сопутствующих вебинаров, содержанием которых могут стать ответы на ваши вопросы и демонстрация реальных кейсов внедрения фреймворка. Для желающих приватности адрес электронной почты для связи: aantonov@swordfishsecurity.com

Полезные ссылки и материалы по теме:

1. https://malotavr.blogspot.com/ блог Дмитрия Кузнецова, эксперта Positive Technologies, одного из немногих специалистов, систематически рассматривающих вопросы сертификации ПО и анализа уязвимостей по ОУД4. Написал несколько материалов про требования ЦБ и ОУД4, см. статьи за 2019 год.

2. https://www.youtube.com/watch?v=0ZoNdaoAeyc&t=658s обзорный вебинар компании RTM Group, посвященный особенностям фреймворка, с участием компании Safe Tech, описывающий реализацию фреймворка в отношении своего продукта.

3. Переведенные стандарты:

   a. ГОСТ 15408-1-2012;

   b. ГОСТ 15408-2-2013;

   c. ГОСТ 15408-3-2013;

   d. ГОСТ 18045-2013;

   e. ГОСТ 57628-2017;

   f. ГОСТ Р 58143-2018.

4. https://en.wikipedia.org/wiki/Common_Criteria Обзор лучших практик по безопасной разработке статья в вики для желающих самостоятельно углубиться в исторические предпосылки.

5. Лучшие практики безопасной разработки:

   a. https://doi.org/10.6028/NIST.CSWP.04232020 обзор актуальных практик SDLC от американского института NIST Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF) от 23.04.2020;

   b. https://www.iso.org/standard/55583.html стандарт ISO/IEC 27034-3:2018 Information technology Application security Part 3: Application security management process;

   c. https://www.pcisecuritystandards.org/document_library стандарты PCI SSC линейки Software Security Framework:

   i. Secure Software Requirements and Assessment Procedures;

   ii. Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures.

6. https://www.cbr.ru/information_security/acts/ Методический документ Банка России ПРОФИЛЬ ЗАЩИТ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций.

Приложение (список сокращений)

По тексту документа использованы следующие сокращения/условные обозначения:

1. 382-П/Положение 382-П Положение Банка России от 9 июня 2012 г. 382-П О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств (актуальная редакция от 07.05.2018, действительно до 01.01.2022 года, отменяется 719-П);

2. 719-П/Положение 719-П Положение Банка России от 4 июня 2020 г. 719-П О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств;

3. 672-П/Положение 672-П Положение Банка России от 09.01.2019 N 672-П О требованиях к защите информации в платежной системе Банка России;

4. 683-П/Положение 683-П Положение Банка России от 17 апреля 2019 г. N 683-П Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента;

5. 684-П/Положение 684-П Положение Банка России от 17.04.2019 N 684-П Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций;

6. 162-ФЗ/Федеральный закон 162 ФЗ Федеральный закон О стандартизации в Российской Федерации от 29.06.2015 N 162-ФЗ;

7. АБС автоматизированная банковская система;

8. ГОСТ Р национальный государственный стандарт Российской Федерации;

9. ИБ информационная безопасность;

10. ИТ информационные технологии;

11. ОО объект оценки;

12. ОУД оценочный уровень доверия (см. ГОСТ/МЭК 15408);

13. ПО программное обеспечение, приложение;

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

15. ISO/IEC International Organization for Standardization(ISO) and theInternational Electrotechnical Commission(IEC);

16. SDLC - Software Development Lifecycle.

Соавтор: (Рустам Гусейнов, специалист по информационной безопасности).