実践 DevSecOps パイプライン ~システム開発へのセキュリティの取り入れ方~

技育祭 2022 春 勉強会

Transcript

1. 実践 DevSecOps パイプライン ~システム開発へのセキュリティの取り入れ方~ 技育祭2022 2022.03.18
2. 森田 浩平 / @mrtc0 GMO ペパボ株式会社 セキュリティ対策室 シニアエンジニア whoami OWASP Fukuoka Chapter Leader セキュリティ・キャンプ 講師 / ステアリングコミッティ https://blog.ssrf.in/
3. Agenda • DevSecOps とは何か、なぜそれが必要とされているのかについて 今日の内容 • Test Driven Security の実施と DevSecOps パイプラインの構築について
4. システム開発で生じる脆弱性
5. Vulnerabilities • XSS (クロスサイトスクリプティング ) • SQL インジェクション • OS コマンドインジェクション • CSRF (クロスサイトリクエストフォージェリ ) • SSRF (サーバーサイドリクエストフォージェリ ) • ディレクトリトラバーサル • オープンリダイレクト • 認可不備 • etc… アプリケーションの脆弱性 共通脆弱性タイプ一覧 CWE概説：IPA 独立行政法人 情報処理推進機構 https://www.ipa.go.jp/security/vuln/CWE.html
6. Vulnerabilities • フィイアウォールやアクセス制御の設定不備 • ミドルウェアの設定不備 • OS / ミドルウェアの既知の脆弱性 • バケットの公開 • etc インフラの脆弱性
7. Vulnerability • クレデンシャルの漏洩 • サプライチェーン攻撃 • 開発環境のセキュリティ • プライバシー周り その他の脆弱性
8. Vulnerability • 攻撃者はアプリケーション、インフラ、組織という巨大で複雑なシステムのなかに、一つの穴 を見つければ勝ちの世界 • 防御側は一つも穴を作るわけにはいかない世界 防御側が不利な世界 防御側はどうやって守る? • 「GitHub にはマルウェアが置いてあって危ないのでアクセスを禁止します」 • 「設定を間違えるといけないので、実行コマンドを指差し確認しましょう」 • 「ライブラリやソフトウェアを使うたびに脆弱性をチェックしましょう」
9. Vulnerability • ガチガチなセキュリティポリシーは生産性を落とす • 技術で担保できるところはソフトウェアを活用しましょう 速く、安全な開発 • 「GitHub にはマルウェアが置いてあって危ないのでアクセスを禁止します」 → AV / EDR で端末を保護しましょう • 「設定を間違えるといけないので、実行コマンドを指差し確認しましょう」 → コード化してレビューしましょう。 Zero Touch Production に取り組みましょう • 「ライブラリやソフトウェアを使うたびに脆弱性をチェックしましょう」 → SBOM などを活用してライセンスや脆弱性の管理をしましょう
10. DevSecOps
11. Vulnerability https://github.com/OWASP/DevSecOpsGuideline/blob/6dcf8669be5d2cc395c4a9a5400f2bc936addb19/assets/images/DevSecOps-cycle.png 開発工程のすべてでセキュリティを考慮する
12. DevSecOps Shift Left
13. Vulnerability • DevSecOps パイプラインを整備する • Insecure な状態に気づける / 自動修復する、自動化された仕組み • Test Driven Security を実践し、一定水準のセキュリティを満たせる仕組みを作る • DevSecOps にチャレンジするカルチャーの醸成 • ツールの導入だけでは成功しない。知識やスキル、マインドセットを持つ DevSecOps を実践するには?
14. DevSecOps パイプラインと Test Driven Security
15. 実践 DevSecOps パイプライン DevSecOps パイプライン
16. 実践 DevSecOps パイプライン DevSecOps パイプライン
17. 実践 DevSecOps パイプライン • 継続的にセキュリティテストが実施できるようにする • すべてのテストが Green になったら Production Deploy できる Test Driven Security
18. 実践 DevSecOps パイプライン なぜ Test Driven Security か Test Driven Security • テストを元に安全な実装ができるようになる • 他部署での再利用性が高い • デプロイ前にセキュリティ上の問題を検出・修正できる (一定の水準が保てる) • 抽象的なガイドラインではなく、具体的な期待値を得られる
19. 実践 DevSecOps パイプライン 継続的なセキュリティテストの戦略として、まずは Baseline を整備する Test Driven Security • デプロイ先に root で SSH ログインできないこと • アプリケーションには HTTPS で接続できること • セッション Cookie には HTTP Only 属性が付与されていること • … DevOps Team と Security Team でこれらのベストプラクティスに合意を取り、 自動テストとして実装していく
20. 実践 DevSecOps パイプライン Application Security Test Driven Security • アプリケーションコードのテストとして実装する • SAST や DAST ツールを利用する https://gitlab.com/gitlab-org/gitlab/-/blob/8400d5c5c27024aa8ef5a7ff2ec1c0b8a98c5cde/spec/lib/gitlab/emoji_spec.rb
21. 実践 DevSecOps パイプライン Test Driven Security Infrastructure Security • Serverspec / Inspec などを使ってサーバーの状態をテストする • tfsec や Conftest などを利用してインフラコードのテストをする control 'sshd-21' do title 'Set SSH Protocol to 2' desc 'A detailed description' impact 1.0 describe sshd_config do its('Protocol') { should cmp 2 } end end package main deny[msg] { input.kind == "Deployment" not input.spec.template.spec.securityContext.runAsNonRoot msg := "Containers must not run as root" }
22. 実践 DevSecOps パイプライン 状態が変更しても検知 / 対応できるようにする = ガードレールを用意する Test Driven Security Production Security • Gatekeeper による制約を満たさないリソースの監査・ブロック • パブリッククラウドの機能を使ったポリシーの作成と違反の検知
23. 実践 DevSecOps パイプライン 運用環境の監視やインシデントレスポンスの準備も必須 Test Driven Security Monitoring / Incident Response • 不審なアクティビティをログとして集約する • 不審なアクティビティを検知できるようにする • プレイブックの作成や対応プロセスの強化
24. 実践 DevSecOps パイプライン DSOMM などを参考に成熟度を上げていく Test Driven Security DSOMM … https://owasp.org/www-project-devsecops-maturity-model/ • Level 1 … セキュリティの基本的なベストプラクティスを理解する • Level 2 … セキュリティの基本的なベストプラクティスを実践する • Level 3 … よりレベルの高いセキュリティの実践 e.g. セキュリティコードレビューの実施、既知の脆弱性の確認やアップデート e.g. SAST / DAST によるスキャンの実施、不要なコンポーネントの削除や権限見直し e.g. 複数スキャナの利用、脅威モデリングの実施、インシデント演習
25. 実践 DevSecOps パイプライン • ソフトウェアによる自動化だけでなく、組織文化の醸成も必要 カルチャー セキュリティテストのスキルや知識を身に着け、マインドセットの切り替えが必要 • セキュリティオンボーディング • セキュリティトレーニング • セキュリティチャンピオン制度
26. 実践 DevSecOps パイプライン
27. 実践 DevSecOps パイプライン DevSecOps パイプライン
28. 実践 DevSecOps パイプライン • アプリケーションやインフラで利用するクレデンシャルをコードに含めない クレデンシャルのハードコードを防ぐ 主な漏洩経路... フロントエンド JavaScript , モバイルアプリ, パブリックリポジトリなど • PaaS の環境変数に設定したり、パブリッククラウドの KMS や Hashicorp Vault にクレデ ンシャルを格納する • うっかり commit / push しないように pre-commit フックを設定しておく
29. 実践 DevSecOps パイプライン • クレデンシャル検出のためのソフトウェアを git の pre-commit で利用する pre-commit フックによるクレデンシャルハードコーディングの防止 • git-secrets … https://github.com/awslabs/git-secrets • detect-secrets … https://github.com/ibm/detect-secrets • Secretlint … https://github.com/secretlint/secretlint • gitleaks … https://github.com/zricethezav/gitleaks • truffleHog … https://github.com/trufflesecurity/truffleHog • ggshield … https://github.com/GitGuardian/ggshield $ cat ~/.gitconfig … [core] hooksPath = ~/.config/githook … $ cat ~/.config/githook/pre-commit #!/usr/bin/env bash git secrets --pre_commit_hook -- "$@" $ git commit -S -s -m 'feat: add config' config.json:2: AWS_ACCESS_KEY_ID: "AKIAIOSFODNN1EXAMPLE" [ERROR] Matched one or more prohibited patterns Possible mitigations: - Mark false positives as allowed using: git config --add secrets.allowed ...
30. 実践 DevSecOps パイプライン Docker イメージにクレデンシャルを含めない $ cat Dockerfile FROM alpine:latest ENV AWS_ACCESS_KEYID AKIAIOSFODNN1EXAMPLE COPY secret.txt /etc/secret.txt RUN rm /etc/secret.txt CMD ["bash"] $ docker build -t app:test . $ docker save app:test -o image.tar $ cat 4d1390ecb1b4f3dffb…6639632b.json | jq .config.Env [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/b in", "AWS_ACCESS_KEYID=AKIAIOSFODNN1EXAMPLE" ] $ tar xf 5dabf394ca5ffcfe…72eab4764286cc4/layer.tar $ cat etc/secret.txt THIS IS SECRET !!!!!1 • ENV で指定した値は残るし、ビルド中に削除したファイルもイメージレイヤに残る • BuildKit の --mount=type=secret オプションやマルチステージビルドなどを利用することを推奨
31. 実践 DevSecOps パイプライン DevSecOps パイプライン
32. 実践 DevSecOps パイプライン 依存ライブラリの脆弱性チェック $ bundle audit Name: actionpack Version: 5.2.2.1 CVE: CVE-2021-22885 GHSA: GHSA-hjg4-8q5f-x6fm Criticality: High URL: https://groups.google.com/g/rubyonrails-security/c/NiQl-48cXYI Title: Possible Information Disclosure / Unintended Method Execution in Action Pack Solution: upgrade to ~> 5.2.4.6, ~> 5.2.6, ~> 6.0.3, >= 6.0.3.7, >= 6.1.3.2 • 利用しているライブラリで脆弱性のあるバージョンを利用していないか検査する • bundle audit … https://github.com/rubysec/bundler-audit • npm audit … https://docs.npmjs.com/cli/v8/commands/npm-audit • Dependabot … https://docs.github.com/ja/code-security/supply-chain-security/managing-vulnerabilities-in-your-projects-dependencies/about-d ependabot-security-updates • Renovate … https://github.com/renovatebot/renovate
33. 実践 DevSecOps パイプライン • Dependabot や Renovate を活用してアップデート可能な環境を作る • 利用しているバージョンと最新バージョンとの乖離状況を確認できる • 自動テストでアップデート可能か検証できる環境を用意できる 依存ライブラリの脆弱性チェック
34. 実践 DevSecOps パイプライン • SAST で脆弱性を作り込んでいないかチェックする SAST (Static Application Security Testing) ツールによる脆弱性検査 • Brakeman … https://github.com/presidentbeef/brakeman • eslint-security-plugin … https://github.com/nodesecurity/eslint-plugin-security • gosec … https://github.com/securego/gosec • CodeQL … https://codeql.github.com/ • Semgrep … https://semgrep.dev/ $ brakeman Confidence: Medium Category: SQL Injection Check: SQL Message: Possible SQL injection Code: where("title like '%#{title}%'") File: app/models/post.rb Line: 8 $ gosec ./… [.../logger.go:49] - G304 (CWE-22): Potential file inclusion via variable (Confidence: HIGH, Severity: MEDIUM) 48: } else { > 49: file, err := os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666) 50: if err != nil {
35. 実践 DevSecOps パイプライン CodeQL job: analyze: … strategy: fail-fast: false matrix: language: [ 'javascript' ] steps: - name: Checkout repository uses: actions/checkout@v2 - name: Initialize CodeQL uses: github/codeql-action/init@v1 with: languages: ${{ matrix.language }} - name: Autobuild uses: github/codeql-action/autobuild@v1 - name: Perform CodeQL Analysis uses: github/codeql-action/analyze@v1
36. 実践 DevSecOps パイプライン Semgrep
37. 実践 DevSecOps パイプライン • Terraform, CloudFormation などのインフラコードを検査し、Missconfiguration を検出 する • e.g. S3 バケットのパブリックアクセス、ファイアウォールの全開放など インフラコードの脆弱性検出 • tfsec … https://aquasecurity.github.io/tfsec • cfsec … https://aquasecurity.github.io/cfsec • kics … https://docs.kics.io/latest/ • conftest … https://www.conftest.dev/ • Shisho… https://shisho.dev/ $ tfsec … Result #6 HIGH Public access block does not ignore public ACLs ────────────────────────────────────────────────────────────────────── ─ s3_bucket.tf Lines 9-13 ───────┬────────────────────────────────────────────────────────────── ─ 9 │ resource "aws_s3_bucket_public_access_block" "bad_example" { 10 │ bucket = aws_s3_bucket.example.id 11 │ 12 │ restrict_public_buckets = false 13 │ } ───────┴────────────────────────────────────────────────────────────── ─ ID aws-s3-ignore-public-acls Impact PUT calls with public ACLs specified can make objects public Resolution Enable ignoring the application of public ACLs in PUT calls …
38. 実践 DevSecOps パイプライン • コンテナイメージに含まれる OS パッケージの脆弱性を検出する コンテナイメージの脆弱性検出 • trivy … https://github.com/aquasecurity/trivy • docker scan (Snyk) … https://docs.docker.com/engine/scan/ • clair … https://github.com/quay/clair $ trivy image --ignore-unfixed python:3.4-alpine … python:3.4-alpine (alpine 3.9.2) ================================ Total: 37 (UNKNOWN: 0, LOW: 4, MEDIUM: 16, HIGH: 13, CRITICAL: 4) +--------------+------------------+----------+-------------------+---------------+---------------------------------------+ | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE | +--------------+------------------+----------+-------------------+---------------+---------------------------------------+ | expat | CVE-2018-20843 | HIGH | 2.2.6-r0 | 2.2.7-r0 | expat: large number of | | | | | | | colons in input makes parser | | | | | | | consume high amount... | | | | | | | -->avd.aquasec.com/nvd/cve-2018-20843 | + +------------------+ + +---------------+---------------------------------------+ | | CVE-2019-15903 | | | 2.2.7-r1 | expat: heap-based buffer | | | | | | | over-read via crafted XML input | | | | | | | -->avd.aquasec.com/nvd/cve-2019-15903 | +--------------+------------------+----------+-------------------+---------------+---------------------------------------+
39. 実践 DevSecOps パイプライン DevSecOps パイプライン
40. 実践 DevSecOps パイプライン • 有償・無償問わず様々なツールが存在する • 無償かつ CI への組み込みやすさでいうと OWASP ZAP に軍配が上がりそう DAST name: OWASP ZAP jobs: zap: name: Run OWASP ZAP steps: ... - name: Import Context run: zap-cli context import app.context - name: Spider run: zap-cli spider -c app -u user $URL - name: Active Scan run: zap-cli active-scan -c app -u user -r $URL - name: Build report run: zap-cli report -f xml -o report.xml - name: Report issue run: report-to-issue report.xml
41. 実践 DevSecOps パイプライン • セキュリティテストを CI で実行するようにし、検知内容を PR にコメントする • e.g. Brakeman + Semgrep • ルールの追加や修正が難しいところも Semgrep などで補完できる(多層防御) スキャンツールを CI に組み込む
42. 実践 DevSecOps パイプライン • GitHub なら Code Scanning Alerts でまとめるのがお得 • スキャン結果を SARIF フォーマットとして出力できれば、 github/codeql-action/upload-sarif@v1 を使ってアップロードできる 脆弱性を管理する
43. 実践 DevSecOps パイプライン • GitHub なら Code Scanning Alerts でまとめるのがお得 • スキャン結果を SARIF フォーマットとして出力できれば、 github/codeql-action/upload-sarif@v1 を使ってアップロードできる 脆弱性を管理する
44. 実践 DevSecOps パイプライン • ツールには誤検知があります • False Negative … 脆弱性が存在するのに見逃してしまう • False Positive … 脆弱性ではないのに検知されてしまう • 脆弱性があるとしても、攻撃可能かどうかはシステムによります • 特定のメソッドや設定の使用が攻撃の条件としてあったりする e.g. CVE-2020-5267 • 攻撃可能だとしても、すぐにアップデートするべきかどうかはシステムによります • Attack Vector が Local だったり、再現性が難しいものであったり 脆弱性との向き合い方 ツールの結果を鵜呑みにせずに、リスク評価を行っていくことが大切
45. 実践 DevSecOps パイプライン • 除外設定やルール・ポリシーの追加などを積極的に行える環境を作る • 誤検知対応時のドキュメント整備や誘導の仕方を工夫する • ルールやポリシーを自動テストできるようにする ルール・ポリシーを育てていく # ruleid: insecure-eval-use eval(user_input) # ok: insecure-eval-use eval('print("Hardcoded eval")') $ python -m semgrep --quiet --test rules/ 1 yaml files tested check id scoring: ----------------------------------------------- (TODO: 2) rules/detect-eval.yaml ✖ insecure-eval-use TP: 1 TN: 2 FP: 1 FN: 1 test: rules/detect-eval.py, expected lines: [5, 12], reported lines: [5, 15] ----------------------------------------------- final confusion matrix: TP: 1 TN: 2 FP: 1 FN: 1 -----------------------------------------------
46. 実践 DevSecOps パイプライン DevSecOps パイプライン例 - Rails
47. 実践 DevSecOps パイプライン 責任共有モデル https://a.sfdcstatic.com/content/dam/www/ocms/jp/assets/pdf/misc/heroku-cloud-security.pdf https://aws.amazon.com/jp/compliance/shared-responsibility-model/
48. まとめ
49. まとめ • Test Driven Security で Shift Left しよう • DevSecOps パイプラインを構想しロードマップを示す • 継続させるために自動化する、コード化する • セキュリティチームと協業しよう • セキュリティチームは DevOps メンバーとコミュニケーションしたい • 速く、安全で、生産性を高める活動にともに取り組む DevSecOps = セキュリティを継続させるためのアプローチの1つ
50. 採用案内 \ セキュリティエンジニアも募集してます!!1 / 「ペパボ セキュリティエンジニア」で検索 !