"Да ладно, Дядя Федя..."

#lol #кулуарка

🛠 AppSec инструменты: синкнемся по определениям

Ремарка сходу:

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

Ощущение, все те же, что как бы интересует AppSec и процесс DevSecOps давненько, но главное бы не впутываться и скорее потеряться теряться (а вдруг там сожрет?), да и в целом так повсеместно в смежном PMI, либо ценности продукта.

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

Окейси, немного вкинули, хоть красивое будет 😄

По этой причине решил подобрать общую подборку определений для toolchain. Это для того, что бы мы концептуально могли понимать друг друга, итак:

- DAST (Dynamic Application Security Testing) – динамическое тестирование безопасности приложения, то есть это имитация реальных атак на приложение во время его работы
- SAST (Static Application Security Testing) – статический анализ кода без его запуска на наличие ошибок и уязвимостей в исходном коде
- SCA (Software Composition Analysis) – анализ состава компонент (зависимостей) ПО
- OSA (Open Source Analysis) – анализ компонент с открытым исходным кодом при попадании в периметр разработки, то есть процесс проверки безопасности open-source компонентов, включающий в себя совокупность инструментов SCA, SCS и анализа лицензионных рисков. 
- SCS (Secure Code Standarts) - набор правил и практик, используемый разработчиками ПО с целью предотвращения нарушений безопасности, неконтролируемых утечек данных и других видов угроз
- License Policy - нарушение лицензионного соглашение, что то на подобии соблюдения авторского права (это что то типа DMCA с с помесью части Trade Secret)
- SBOM (Software Bill of Materials) - инвентаризационный список всех компонентов (пакетов, библиотек), используемых в разрабатываемом приложении или необходимых для его работы
- NVS (Network Vulnerability Scanner) - сетевой сканер уязвимостей с уклоном на L3/L4 c ограниченными DAST-возможностями (не тривиальненько)
- BCA (Bytecode and Container Analysis) – анализ бинарного кода и состава контейнеров
- CIS (Container Image Scanner) – сканирование образов контейнеров на уязвимости (Container Security)
- CSPM (Cloud Security Posture Management) – контроль конфигураций Kubernetes и облачных сред
- SM (Secret Management) – управление секретами

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

#toolchain #appsec #devsecops #specialty

😂 Must-have: «симулятор программиста-аутиста»

Можно поиграть за разраба, пытающего в социум и работать корректно, а теперь представьте еще и ИБ приходит с ноги?

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

Местами перебор даже для прожженных, но "отборный и искрометный" юмор показывает, что в целом как то напоминает ... (подставьте сами)

#lol #кулуарка

🤔 Что такое авторское право и практика DMCA (с)

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

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

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

Давай разберем, что это?

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

DMCA (Digital Millennium Copyright Act) — это закон об авторском праве в digital путем использования механизма «notice and takedown», то есть: автор/ правообладатель может отправить жалобу и твой контент удалят без суда и разбирательств. Обычно это именно тот знак копирайтерства как (с).

Авторское право для РФ это конкретное цельное произведение, как Объект интеллектуальной собственности, а для DMCA это любой созданный контент человеком, то есть: если в РФ я сделал картинку и ее переиспользуют 1 в 1, то это кейс нарушения АП, а если изменяют больше 40% - нет, а вот для DMCA оба случая указывают, что это нарушение.

Теперь важные для тебя особенности, запоминай:

- Объекты авторского права/ интеллектуальной собственности - результат творческого труда, независимо от назначения
- Субъект авторского права - физическое лицо или соавторы, чьим творческим трудом оно создано
- Права не могут возникнуть у юридического лица или у ИИ (включая промты)
- Любое изменение объекта авторского права уже классифицируется как отдельное произведение, при условии изменений более 40% материала или рерайтинга этого контента
- Полного отчуждение авторского права не существует, вы можете всегда оставить за собой права опубликовать, что любая модификация материалов должна быть с вашим упоминанием
- Полные права всегда остаются за вами и при необходимости вы можете их возобновить, если условия передачи отсутствовали и/ или были нарушены при использовании
- Юридические лица могут получить исключительное разрешение (не полные права) на использование произведения:

-- Договор отчуждения только с отдельным видом стоимости за работы, которые обязательно должны быть включены на весь срок действия
-- Лицензионный договор на использования в определённых пределах (так работаат политика например игровой индустрии)
-- Договор авторского заказа по техзаданию заказчика, где формулировка на исключительные права только в рамках условий
-- Служебные произведения принадлежат все работодателю (ст. 1295 ГК РФ), если иное не предусмотрено договорными отношениями

- Типы лицензирования носят разный характер для проприетарного, а также свободного распространения (разберем отдельно). Пример:

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

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

#toolchain #compliance #reco #specialty

🛠 VI/ VIM: немного полезной навигации, как структуры

Что-то резко вспомнил про vi/ vim, nano, etc. В итоге самое комфортная работа на vim для меня, практика еще показывает когда учился на старых добрых тачках ubuntu, fedora, freebsd на консольке/ терминале. Решил давно себе заготовочку сделать и поделиться с вами. Так скажем для инфо.

Режимы работы

• Режим команд (Command mode) - используется для выполнения команд. При запуске Vim, вы находитесь в этом режиме.
• Режим вставки (Insert mode) - используется для ввода текста. Для перехода в этот режим, нажмите клавишу "i".
• Режим замены (Replace mode) - используется для замены существующего текста. Для перехода в этот режим, нажмите клавишу "R".
• Режим визуального выделения (Visual mode) - используется для выделения текста для копирования, вырезания или изменения. Для перехода в этот режим, нажмите клавишу "v"

Навигация

• h - переместить курсор влево
• j - переместить курсор вниз
• k - переместить курсор вверх
• l - переместить курсор вправо
• w - переместить курсор на начало следующего слова
• b - переместить курсор на начало предыдущего слова
• e - переместить курсор на конец текущего слова
• 1 - переместить курсор в начало строки
• $ - переместить курсор в конец строки
• gg - переместить курсор в начало файла
• G - переместить курсор в конец файла

 Редактирование текста

• i - вставить текст перед курсором
• a - вставить текст после курсора
• o - вставить новую строку после текущей строки и перейти в режим вставки
• dd - вырезать текущую строку
• yy - скопировать текущую строку
• p - вставить скопированный или вырезанный текст после курсора
• u - отменить последнее действие
• Ctrl + r - повторить отмененное действие

Сохранение и выход из редактора

• :w - сохранить файл
• :q - выйти из Vim
• :wq - сохранить файл и выйти

#toolchain #reco

"По братски, для своих"

#lol #кулуарка

🛠 SBOM: легковесная генерация cdxgen

Ранее, мы с тобой посмотрели тут, что такое Software Bill of Materials SBOM. Мы разобрали как он выглядит, зачем и почему используется. Давай теперь посмотрим на сам инструмент и на то как его использовать, но он с особенностями.

Инструмент:

cdxgen - CLI инструмент для автоматизации SBOM в формате CycloneDX. Основные функции как анализ метаданных и лицензий, чтение manifest файлов. Из важного у него только генерация одного формата. Тип лицензии: Apache License 2.0.

Конвертация SBOM в формат, отличный от CycloneDX потребует конвертор. Зависимости, собранные вручную либо перепакованные могут не определяться или частично. Совместим с Dependency-Track для управления SBOM, включая Trivy, Grype.

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

Применение:

sudo npm install -g @cyclonedx/cdxgen
cd <Path to source code>

docker run --rm -e CDXGEN_DEBUG_MODE=debug -v /tmp:/tmp -v $(pwd):/app:rw -t ghcr.io/cyclonedx/cdxgen:master -r /app -o /app/bom.json # либо -p для вывода в консоли/ терминале

cdxgen -t java -o bom.json --server-url https://deptrack.server.com --api-key "token" --project-group ... # пример отправки на Dependency-Track

Флаги:

cdxgen [-t], [-o], [-p], [-r], [-h], [-v]
 
-t,  --type # если не указывать этот параметр, то соберет вообще все зависимости, которые сможет
      --exclude-type # убрать из обработки

-o, --output # сохранение в формате - XML, JSON
-p, --print # вывод "дерева SBOM" в виде таблицы
-r,  --recurse // кекурсивное сканирование по директориям
      --no-recursive # базово по файлам в корневой директории
      --deep
      --fail-on-error # при сбое сбора одного из типов компонент высвечивает earning
      --technique # по умолчанию стоит auto режим, но можно задать "source-code-analysis", "binary-analysis", "manifest-analysis", "hash-сomparison", "instrumentation", "filename"
      --required-only # для исключений/ ограничений

Поддерживаемые BOM:

• Cryptography CBOM - Java, Python
• Operations OBOM - Linux container images
• Software-as-a-Service SaaSBOM - Java, Python, JavaScript, TypeScript, PHP
• Attestations (CDXA)
• Vulnerability Disclosure Report (VDR) - OWASP depscan VDR

Pipeline:

sbom:
  image: node:20-alpine
  stage: test
  script:
    - npm i -g @cyclonedx/cdxgen
    - cdxgen -r . -o sbom.json
  artifacts:
    paths: [sbom.json]

Итого: инструмент достаточно прост, поможет собирать зависимости и контролировать их, например полезно для сверки используемых компонент на проекте и при merge/ pull requeste от contributor. И да, конечно же, любимая история прописания пути для registry и использования только безопасных зависимостей.

#toolchain #sbom

🎧 Интервью с ассоциацией BISA по рискам ИБ и безопасной разработке

Салют,
Нашёл бородатое в закромах, но до сих пор актуальное интервью с ассоциацией BISA @bisafm - про безопасную разработку ПО, риски ИБ и как дружить все это вместе.

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

По сути, три года прошло, а вопросы то теже:
Как встроить безопасность в разработку, не похоронив скорость TTM, и зачем бизнесу вообще этот DevSecOps.

О чём говорили

- Кто такие DevSecOps и почему «Sec» - это не инструмент, а культура
- Как построить SDLC, где безопасность не мешает релизам
-⁠ Зачем банку Quality Gate и как он снижает риски ещё до продакшена (привет моим кайфовым коллегам из Росбанка, мы с вами делали вещи)
- Как риск-менеджмент реально связан с безопасной разработкой
- Что такое ограничения и допущения для бизнес-ориентированного подхода с рисками ИБ?
- Как и почему вообще нужна эта история? Затронули немного регуляторку (на то время любимое, как must-have)
- Почему Shift-Left - это не лозунг, а способ экономить время и деньги

Почему стоит посмотреть

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

Timestamp:

▪️00:35 - Что такое DevOps
▪️1:50 - DevSecOps как процесс разработки безопасного ПО
▪️3:15 - Как риск-менеджмент связан с разработкой безопасного ПО
▪️6:52 - Что дает банку внедрение разработки безопасного ПО и ее взаимодействие с управлением рисками
▪️8:59 - Какие риски банка и клиентов снижаются при таком подходе
▪️10:20 - Какие плюсы это дает командам разработки
▪️11: 59 - Как оценивается зрелость реализации этих процессов в командах
▪️12:30 - Почему Росбанк решил внедрять процесс разработки безопасного ПО

🎬 YouTube

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

#подкаст #devsecops #appsec #compliance #pmi #gost

🤔 Лицензирование: свободное и проприетарное

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

Проприетарные лицензии:

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

Принципы:
- Ограничение на коммерческое использование ПО
- Ограничение на распространение ПО
- Ограничение на изучение и модификацию ПО

По объему выделяют:
- OEM лицензии (поставляются вместе с оборудованием)
- Однопользовательские лицензии
- Многопользовательские лицензии
- Корпоративные лицензии (для организаций)

Свободные лицензии:

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

Виды:
- Permissive (разрешительные)
- Strong Copyleft Licenses
- Weak Copyleft Licenses
- The Unlicense (лицензии на передачу кода в общественное достояние)

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

#toolchain #licenses

"админские забавы"

#lol #кулуарка

🛠 База DevSecOps & AppSec Toolchain

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

DevSecOps как автоматизация производства безопасного ПО для:

- Выполнения требований регулятора,
- Снижения рисков ИБ (утечка, киберпреступления и тд) и угроз недопустимых событий
- Поддержки Time-to-Market TTM
- Контроль внешних библиотек и используемых компонент
- Повышения репутационного уровня и развития конкурентноспособности, в связи с нынешней ситуацией на рынке РФ
- Оптимизации решений по Secure SDLC
- Выполнение требований к проектам, минимизации потерь при разработке

Основная цель

Использование лучших практик по организации защиты информации и периметра, выстраивание процессного подхода и повышения Servise Relationships Management. Делаем потому что может дать снижение ФОТ на устранение сработок, а также сократить показатели прерывания процессов на тестирования ИБ до 20%.

Сейчас происходит пролонгирование сроков для выполнения требований регуляторов, стандартов и процессов внедрения DevSecOps. Поэтому наша цель повысить уровень обеспечения ИБ со стороны бизнеса, а именно:

- TTM разработанного функционала
- Повышения уровня осведомленности сотрудников
- Развитие гильдии Security Champions
- Повышения взаимодействия внутри команд разработки и ИБ
- Внедрение контроля разработки на всех стадиях жизненного цикла
- Оптимизация операционно-технических процессов
- Расследование инцидентов и проведение проверок по устранению последствий
- Выработка мер реагирования и стандартизации процесса (DMAIC)
- Повышение уровня зрелости DASA DevOps практик
- Application Security Testing Orchestration
- Shift-Left-подход и Secure-by-Design

Итого: это может дать возможность роста и развития направления по DevSecOps, что позволит повысить уровень риск-менеджмента и нивелирования возможных инцидентов со стороны разработки ПО, как in-house, так и от вендоров. Аналогично может дать возможность повышения уровня TTM в безопасном исполнении. Может позволить контролировать SDLC и далее обеспечить Secure SDLC

Это позволит в условиях текущей ситуации на рынке обеспечить с ростом вовлечения в процесс безопасность выпускаемых функциональных и не функциональных features. Это позволит контролировать средствами AppSec как триггеров выпускаемых features в PROD и автоматизации процессов ИБ.

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

#devsecops #appsec #toolchain #pmi #specialty #riskanalys #techsolution

🛠 .dockerignore: игнорирование при сборке образа

Салют,
Мы с тобой смотрели принцип игнорирования для .gitignore вот тут, а сейчас посмотрим принцип для .dockerignore. То есть мы посмотрим, что позволяет игнорировать docker при сборке образа.

Игнорирование аналогично .gitignore:

- Уменьшает размер
- Ускоряет сборку
- Повышает безопасность при правильных ограничениях и использования аналогов по типу хранения артефактов в packages

В .dockerignore это правила, которые поддерживают пути, шаблоны, инверсии исключений:
- Пути и файлы: some_docs/
- Шаблоны: *.log
- Игнорирование: `!config/default.json

dockerignore:

node_modules
build/
*.log // игнорирование всех логов
.env 
!.env.example // оставляем конкретный артефакт

Как собирать:

docker build -t with_ignore -f Dockerfile .
docker run --rm with_ignore

Итого: выводы аналогичны .gitignore, но шире, так как сборка уже выходит дальше, чем git repo. Для генерации данного файла существуют онлайн сервисы, на подобии этого dockerignore-generator. Автогенераторы позволяют обще собрать шаблон файла. Кстати, для helm-чартов аналогично используется по такому же принципу helmignore.

#toolchain #reco

Отлично звучит, в наших реалиях, для стартапа

#lol

🥶 DMAIC: как система ценности для оптимизации

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

Поговорим давай про систему для оркестрации хауса ИБ в процессах разработчиков. Я часто использую в своих выражениях обороты связанные с профильными штуками. Мы же с вами все имеем профессиональную деформацию, вот и я в свое время получив сертификацию DASA DevOps Product Manager начал обращать больше внимание на это.

В процессах разработки и отработке уязвимостей часто слышу:

- «Надо оптимизировать пайп, он с тормозами катится»
- «Снизить фолсы иначе снова будут вопросы»
- «Эти уязвимости не эксплуатируются, докажи нам»
- «Давай в технический долг и потом разберем»
- «Зачем нам этим заниматься? Мы же обновляемся»
- «Памагите» (😂)

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

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

Следовательно, DMAIC

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

Lean Six Sigma,

которую можно отлично применять в DevSecOps.

Модель:

D — Define (Определи

ть

)

- сначала формулируем проблему и цель. Например: “сократить ложные срабатывания SAST на 30% без потери покрытия”

M — Measure (Измерить)

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

A — Analyze (Проанализировать)

- находим первопричины, где точка сбоя — инструмент, конфигурация, процесс триажа или вовсе человеческий фактор и тд

I — Improve (Улучшать)

- внедряем изменения: обновляем правила, автоматизируем, добавляем callback-actions, оптимизируем job анализаторов, пишем политики, модернизируем пайплайн и тд

C — Control (Контроль)

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

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

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

DMAIC помогает переводить улучшения из «кажется, стало лучше» в измеримую практику. Работает для чего угодно: от настройки пайплайнов до зрелости AppSec-процессов.

#pmi #devsecops #riskanalys #roadmap

Когда собираешь с нуля все вокруг себя

#lol #кулуарка