🤔 Kaizen Event: +10/10 к эффективности

Салют,
Ранее мы с тобой посмотрели, что такое DMAIC.

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

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

Перед этим, предлагаю вспомнить, что такое DMAIC:

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

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

Почему мы на это смотрим?

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

Kaizen Event — как раз про достижения результатов и изменений, которые реально эффективны и дают показатели в которкий срок.

По сути это сфокусированный спринт улучшений, когда команда на несколько дней ставит мир на паузу, чтобы сделать один конкретный процесс лучше. Не «оптимизировать всё», а убрать реальную

Как это работает

- Выбираем точку боли: что мешает чаще всего? проблема повторяющихся уязвимостей из-за откатов версий? Фолсы? Вечная очередь при сканированиях? By-pass критериев качества ИБ? Берём самое раздражающее место — туда и бьём

- Измеряем текущее состояние на количественно-качественных характеристиках: среднее время проверки сборки — 19 мин. Хотим 12. Либо долгий триаж уязвимостей - автоматизируем контроль показателей ASPM и делаем уникальные политики для проекта

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

- Делаем улучшение сразу без бесконечных тикетов и совещаний.
Собрались → сделали → проверили

- Закрепляем результат, как пример создаём новый стандарт, метрику, автоматизацию и ид — чтобы улучшение не растворилось через месяц

Почему Kaizen Event реально работает?

- Фокус на конкретной боли, а не на всём подряд
- Быстрый результат → растёт вовлечённость
- Команда чувствует, что может менять систему и они что то значят, ростут их компетенций и соответствующий кост, а не просто “работать по процессу”

Такие Kaizen-сессии отлично заходят на темах вроде:

- Сокращение времени проверки пайплайна и получение callback от анализаторов с результатов по метаданным типа количество плотности уязвимостей
- Оптимизация правил для SAST/ SCA, автоматизация сценариев для DAST и иное
- Ускорение триажа фолсов исходя из группировки
- Анализ рисков по уязвимостям, которые реально аффектят систему
- Настройка фидбека между безопасниками и разработкой
- Внедрение Security Champions и процессов DevSecOps

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

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

#pmi #devsecops #riskanalys #roadmap #pmcases #humanres

🥶 DevSecOps и сертификация CI/CD по ГОСТ 56939

Салюты,
Я тут пока отвалился не надолго, скоро вернусь с качественным обновлением для канала, будет кайф.

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

Зачем бизнесу?

- Экономия ресурсов — исправлять уязвимости на ранних этапах дешевле и проще
- Снижает риски инцидентов, в следствии потенциального прямого и косвенного урона в виде финансовых потерь, то есть повышает доверие к компании на рынке
- Защищенность ПО от уязвимостей и киберугроз, то есть как и на каких этапах учитывать ИБ
- Развитие сотрудников и качества, стабильности разработки, то есть повышает конкуретноспособность
- Важна при работе с государственным сектором и крупными заказчиками от их требований, если компания разрабатывает или вносит изменения в СЗИ, а также работает с объектами КИИ, ГИС и/или ИСПДн
- Стандарт помогает быстро и уверенно проходить контроль со стороны заказчиков и/или независимых аудиторов
- Подтверждает, что процессы отвечают требованиям к защищённой разработке (если проходим 2024 и не просто закрываемся бумажками в большей части ИСП РАН спрашивает конкретику, но все мы знаем как проходит сертификация)

Основные поинты согласно приказу 240

- Орган по сертификации ИСП РАН: в порядке расписаны сроки,
где большую часть времени занимает работа по сертификации
- Заявка с указанием основной информации и приложение
с руководством безопасной разработке во ФСТЭК России
- Сертификация проводится на базе изготовителя с проверкой соответствия, в том числе оценка документации и оборудования
- Заключение о соответствии процессов (Заявка на рассмотрении в течение 15 рабочих дней):
-- При несоответствии, изготовитель устраняет их и уведомляет для повторной сертификации. 
-- При соответствия подготавливается проект сертификата, который рассматривается ФСТЭК России.

Ключевые маркеры ГОСТ 56939-2024

- Стандарты ГОСТ 56939 и ГОСТ 15408 являются основой для подтверждения безопасности процесса разработки
- Сертификат выдается компании, а не только на конкретное приложение
- Сертификация действует до 5 лет и может охватывать не один, а несколько продуктов, - все компоненты, зависимости, библиотеки и инструменты, участвующие в разработке
- Органы сертификации могут в любой момент проверить произвольное приложение из конвейера или готовый продукт. Это исключает возможность «подготовить только один проект для отчёта».
- В фокусе — не только код, но и сам процесс: сборка, тестирование, управление версиями, деплой. Проверка может охватывать сразу несколько CI/CD конвейеров, используемых в организации.
- Формальные документы (процедуры, политики, регламенты) должны соответствовать тому, как на самом деле устроен процесс разработки.
- Все программные компоненты и артефакты (исходники, библиотеки, сборки) должны храниться в проверенном и контролируемом хранилище, чтобы обеспечить воспроизводимость и защищённость.
- Сертификацию начинают с конкретного продукта, и только затем переходят к оценке самого процесса разработки. Исключения возможны, но крайне редки.
- Продукты и процессы должны быть связаны с конкретными техническими требованиями и угрозами. Это фиксируется в проектной документации и проверяется на соответствие.
- Для сертификации потребуется собрать более 100 требований и подтвердить их выполнением через ~120 артефактов — это технические документы, тесты, отчёты, описания процессов и систем.

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

#devsecops #pmi #specialty #gost #compliance

🛠 Autoswagger: легкая проверка на доступность без авторизации

Салют,
Сталкивался пару раз с общим описанием Autoswagger by intruder.io. Решил посмотреть быстрый и легковесный инструмент.

Инструмент позволяет пробежаться по торчащим ручкам API наружу у продукта. Поэтому мне захотелось поделиться с тобой его особенностями. Тип лицензии: BSD 3-Clause License. Установка как python библиотекf, для использования в CLI.

Какой функционал может:

- Сканирует домены для обнаружения открытой документации API, где есть возможность указания отдельно OpenAPI спецификации
- Анализ спецификации и формирование списка конечных точек для тестирования. Отправляет запросы с допустимыми параметрами из документации и помечает любые конечные точки, возвращающие данные без надлежащего контроля доступа, т.е. без ошибок 401 или 403

Пример: сработал явно на вектор по 429 - Too Many Requests и позволил понять, что надо смотреть в сторону тестирования лимитов запросов (простое)

- Определяет конфиденциальные данные в ответе, как учетные данные, персональную информацию PII
- Использование флага --brute, чтобы попытаться обойти проверки, что помогает выявить уязвимости в конечных точках, которые отклоняют стандартные входные данные, но принимают определённые форматы данных, значений

Применение:

git clone git@github.com:intruder-io/autoswagger.git
pip install -r requirements.txt
python3 autoswagger.py -h
autoswagger--help 
python3 autoswagger.py https://example.ru/api/users/swagger/v1/swagger.json  -v -risk -all

Флаги:

autoswagger.py [-h] [-v] [-risk] [-all] [-product] [-stats] [-rate RATE] [-b] [-json] [urls ...]

-h, --help # Показать это справочное сообщение и выйти
-v, --verbose # Включить подробный вывод
-risk # Включить в тестирование запросы, отличные от GET
-all # Включить все коды состояния HTTP в результаты, исключая 401 и 403
-product # Вывести все эндпоинты в формате JSON, пометив те, что содержат PII или имеют большие ответы
-stats # Показать статистику сканирования. Включается в JSON при использовании -product или -json
-rate RATE # Установить лимит скорости в запросах в секунду
-b, --brute # Включить исчерпывающее тестирование значений параметров
-json # Вывести результаты в формате JSON в режиме по умолчанию

Сценарии:

1. Режим автообнаружения OpenAPI-спецификации
- принимает доменное имя - example.com
- выполняет сканирование целевого домена, проверяя стандартные пути к OpenAPI/ Swagger-документации типа /openapi.json, /swagger.json, /api-docs, /v3/api-docs
- если спецификация обнаружена, инструмент парсит её и извлекает все доступные эндпоинты
- для каждого эндпоинта выполняет автоматизированные запросы GET, POST, PUT, DELETE и др., если они указаны, без авторизации, анализируя ответы: статус-коды, тело ответа, headers

2. Режим работы с предоставленной спецификацией
- инструмент принимает на вход одну или несколько OpenAPI-спецификаций в формате JSON/YAML, локальные файлы или URL
- парсит каждую спецификацию, извлекая все эндпоинты и поддерживаемые HTTP-методы
- для каждого эндпоинта выполняет автоматизированные запросы без авторизации, фиксируя отклонения - ошибки 5xx, неожиданные 200/403, утечки данных и т. д.

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

#toolchain #reserch #dast

🛠 Bandit как linter на pre-commit

Салют,
Давай сегодня посмотрим с тобой на SAST для python. Bandit смотрим как линтер, потому что удобно использовать без разбора и углубления в бизнес логику, потому что инструмент не умеет в это. Тебе же полезен для интеграции в команду разработки на python.

Bandit парсит код каждого файла проекта в AST (Abstract Syntax Tree - дерево абстрактного синтаксиса) и прогоняет набор правил (плагины через entry points). Тип лицензии: Apache-2.0 license. Форматы отчетов: csv, custom, html, json, screen, txt, xml, yaml.

Самое классное, что если использовать wemake-python-styleguide в совокупности с Bandit как анализатором, то мы решаем вопросы разименования, затенения встроенных функций, когнитивной сложность, а также проблемы с непоследовательными возвратами, неправильными разрывами строк, непоследовательными выражениями и сработка с явными уязвимостями.

Команды

python -m venv .venv
pip install bandit

bandir -r ./my_python_project/  # Рекурсивное сканирование

--severity-level
--confidence-level # Пороги  
--profile 
-t # Выбор правил
-s # Пропуск правил
nosec # Точечное игнорирование

docker pull ghcr.io/pycqa/bandit/bandit:<tag>
 
cosign verify ghcr.io/pycqa/bandit/bandit:latest \ # проверка подписи образа перед использованием
--certificate-identity https://github.com/pycqa/bandit/.github/workflows/build-publish-image.yml@refs/tags/<version> \
--certificate-oidc-issuer https://token.actions.githubusercontent.com

Файл конфигурации

# .bandit
exclude_dirs: ['tests', 'venv']
skips: ['B101', 'B311']

any_other_function_with_shell_equals_true:
  no_shell: ['subprocess.Popen']

hardcoded_password_string:
  hardcoded_password_string_re: '(?i)(password|passwd|pwd)'

Использование как pre-commit

#.pre-commit-config.yaml
repos:
-   repo: https://github.com/PyCQA/bandit
    rev: 1.7.5
    hooks:
    -   id: bandit
        args: ['-ll', '-ii']

CI/CD

variables:
  BANDIT_SEVERITY: "medium"
  BANDIT_CONFIDENCE: "medium"
  BANDIT_OUTDIR: "bandit-report"
      
bandit_scan:
  stage: security
  image: ghcr.io/pycqa/bandit/bandit:<tag>
  script:
    - mkdir -p "$BANDIT_OUTDIR"
    - bandit -r . \
        --severity-level="$BANDIT_SEVERITY" \
        --confidence-level="$BANDIT_CONFIDENCE" \
        -f json  -o "$BANDIT_OUTDIR/bandit.json"

pipeline {
  agent any
  options { timestamps() }
 
  environment {
    BANDIT_SEVERITY   = 'medium'
    BANDIT_CONFIDENCE = 'medium'
    REPORT_DIR        = 'bandit-report'
  }
 
  stages {
    stage('Setup Python venv') {
      steps {
        sh '''
          python3 -m venv .venv
          . .venv/bin/activate
          pip install --upgrade pip
          pip install bandit
          mkdir -p "${REPORT_DIR}"
        '''
      }
    }
    stage('Bandit Scan') {
      steps {
        sh '''
          . .venv/bin/activate
          bandit -r . --severity-level=${BANDIT_SEVERITY} --confidence-level=${BANDIT_CONFIDENCE} \
            -f json  -o ${REPORT_DIR}/bandit.json
          bandit -r . --severity-level=${BANDIT_SEVERITY} --confidence-level=${BANDIT_CONFIDENCE} \
            -f sarif -o ${REPORT_DIR}/bandit.sarif
          bandit -r . --severity-level=${BANDIT_SEVERITY} --confidence-level=${BANDIT_CONFIDENCE} \
            -f html  -o ${REPORT_DIR}/bandit.html
        '''
      }
    }
  }
 
  post {
    always {
      archiveArtifacts artifacts: 'bandit-report/**', fingerprint: true
    }
    unsuccessful {
      script { currentBuild.result = 'UNSTABLE' }
    }
  }
}

Итого: сам SAST дает AST-подход без исполнения кода, где baseline позволяет внедрять постепенно и расширяем через плагины, но большое количество некорректных правила дающих FP, которые надо перебрать руками. Инструмент легковесен, но не как целевой SAST, а очень комфортное решение для проверок до Merge/ Pull Requeste. Совместно с wemake-python-styleguide решается проблема структуры и стилистики кода внутри команды разработки.

#toolchain #sast

Типовые "грешки" использования JWT

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

Так вышло, что хотел бы поделиться с вами интересным подходом, чем-то напоминает классическую модель. У этих ребят, занимающихся консалтингом и Compliance, есть обзоры в части рисков ИБ по теме уязвимостей в разработке.

Один из интересных постов вот этот. Автор разбирает обход аутентификации в вебе, описывает вектора атак и как минимизировать их. Прочитав вы можете увидеть, что в зависимости от кейса можем акцентироваться на самом принципе и докрутить.

Давай посмотрим на JWT сессии в том же ключе на примере обычного внедрения

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

JWT (Json Web Token) токен аутентификации пользовательской сессии, то есть самого пользователя для запросов к методам API. Нужен для передачи учетных данных к серверу на каждый вызываемый метод.

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

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

- путем ограничения его временем жизни
- валидация изначально проверяет время жизни токена
- blacklist
- защищенный канал передачи данных
- сброс сессии после конца времени жизни токена в неактивном состоянии
- привязка к action button в случае активности пользователя внутри окна аутентифицированного приложения
- дебажить на jwt.io вне команды разработки для тестов ИБ путем модификации
- не передавать чувствительные пользовательские данные (

база

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

Получается, что мы имеем access token - доступ при каждом запросе, refresh token - перевыпуск пары, а также указанное значение жизни по time-delay. Сама структура состоит из данных в payload, header как тип и алгоритм шифрования, cripto signature.

Итого: базово механизм реализует только обновление и передачу, но без доп мер защиты могут быть реализованы атаки по типу:

- отсутствие проверки подписи, где если поставить alg none, сервер неподписанный токен примет в явном виде с payload и права например admin
- манипуляция ключевыми идентификаторами из-за отсутствия сложности key id
- подбор ключа симметричной подписи и подбор ключевой фразы
- для ассиметричных путем изменения алгоритма через hex с использование логических ошибок реализации
- перехват токена и UrlDecode

И да, все-таки стоит посмотреть на коллег и их кейсы в AKTIV.CONSULTING @aktivcons.

#reco #reserch #secrets #pmcases