📗
owasp-devsecops-guideline-ja
  • OWASP DevSecOps Guideline ja
  • OWASP DevSecOps ガイドライン 日本語版
    • OWASP DevSecOps ガイドライン
  • V0.3
    • 0-概論 (Intro)
      • 0-1-序文 (Intro)
      • 0-2-概要 (Overview)
    • 1-要員 (People)
      • 1-1-チーム形成 (Shape-the-team)
        • 1-1-1-セキュリティチャンピオン (Security-champions)
      • 1-2-トレーニング (Training)
        • 1-2-1-セキュアコーディング (Secure-coding)
        • 1-2-2-セキュリティ CI/CD (Security-CICD)
    • 2-プロセス (Process)
      • 2-1-設計 (Design)
        • 2-1-1-脅威モデリング (Threat-modeling)
      • 2-2-開発 (Develop)
        • 2-2-1-コミット前 (Pre-commit)
          • 2-2-1-1-プレコミット (Pre-commit)
          • 2-2-1-2-シークレット管理 (Secrets-Management)
          • 2-2-1-3-コードのリンティング (Linting-code)
          • 2-2-1-4-リポジトリ堅牢化 (Repository-Hardening)
      • 2-3-ビルド (Build)
        • 2-3-1-静的解析 (Static-Analysis)
          • 2-3-1-1-静的アプリケーションセキュリティテスト (Static-Application-Security-Testing)
          • 2-3-1-2-ソフトウェアコンポジション解析 (Software-Composition-Analysis)
          • 2-3-1-3-Infastructure as Code (Infastructure-as-Code-Scanning)
          • 2-3-1-4-コンテナセキュリティ (Container-Security)
            • 2-3-1-4-1-コンテナスキャン (Container-Scanning)
            • 2-3-1-4-2-コンテナ堅牢化 (Container-Hardening)
      • 2-4-テスト (Test)
        • 2-4-1-インタラクティブアプリケーションセキュリティテスト (Interactive-Application-Security-Testing)
        • 2-4-2-動的アプリケーションセキュリティテスト (Dynamic-Application-Security-Testing)
        • 2-4-3-モバイルアプリケーションセキュリティテスト (Mobile-Application-Security-Test)
        • 2-4-4-API セキュリティ (API-Security)
        • 2-4-5-構成ミスチェック (Misconfiguration-Check)
      • 2-7-運用 (Operate)
        • 2-7-1-クラウドネイティブセキュリティ (Cloud-Native-Security)
        • 2-7-2-ログ記録と監視 (Logging-and-Monitoring)
        • 2-7-3-ペンテスト (Pentest)
        • 2-7-4-脆弱性管理 (Vulnerability-Management)
        • 2-7-6-侵害と攻撃のシミュレーション (Breach-and-attack-simulation)
    • 3-ガバナンス (Governance)
      • 3-2-データ保護 (Data-protection)
      • 3-1-コンプライアンス監査 (Compliance-Auditing)
        • 3-1-1-コンプライアンス監査 (Compliance-Auditing)
        • 3-1-2-Policy as Code (Policy-as-code)
        • 3-1-3-セキュリティベンチマーク (Security-benchmarking)
      • 3-3-レポーティング (Reporting)
        • 3-3-1-成熟度追跡 (Tracking-maturities)
        • 3-3-2-脆弱性一元管理ダッシュボード (Central-vulnerability-management-dashboard)
  • V0.2
    • 0-概論 (Intro)
      • 0-1-序文 (Intro)
      • 0-2-概要 (Overview)
    • 1-導入 (Init)
      • 1-1-チーム形成 (Shape-the-team)
        • 1-1-1-セキュリティ担当者 (Security-champions)
      • 1-2-トレーニング (Training)
        • 1-2-1-セキュアコーディング (Secure-coding)
        • 1-2-2-セキュリティ CI/CD (Security-CICD)
    • 2-コミット前 (Pre-commit)
      • 2-1-プレコミット (Pre-commit)
      • 2-2-脅威モデリング (Threat-modeling)
      • 2-3-リポジトリ堅牢化 (Repository-hardening)
      • 2-4-シークレット管理 (Secrets-Management)
      • 2-5-コードのリンティング (Linting-code)
    • 3-コミット CI (Commit-CI)
      • 3-2-インタラクティブアプリケーションセキュリティテスト (Interactive-Application-Security-Testing)
      • 3-1-静的解析 (Static-analysis)
        • 3-1-1-静的アプリケーションセキュリティテスト (Static-Application-Security-Testing)
        • 3-1-2-ソフトウェアコンポジション解析 (Software-Composition-Analysis)
        • 3-1-3-コンテナセキュリティ (Container-Security)
          • 3-1-3-1-コンテナスキャン (Container-scanning)
          • 3-1-3-2-コンテナ堅牢化 (Container-hardening)
        • 3-1-4-Infastructure as Code (Infastructure-as-code)
    • 4-継続的デリバリ CD (Continuous-delivery-CD)
      • 4-1-動的アプリケーションセキュリティテスト (Dynamic-Application-Security-Testing)
      • 4-2-モバイルアプリケーションセキュリティテスト (Mobile-Application-Security-Test)
      • 4-3-API セキュリティ (API-Security)
      • 4-4-設定ミスのチェック (Miss-Configuration-Check)
    • 5-デプロイ CD 稼働開始 (Deploy-CD-Golive)
      • 5-1-鍵と証明書の管理 (Key-and-certificate-management)
      • 5-2-クラウドネイティブアプリケーション保護プラットフォーム (Cloud-Native-Application-Protection-Platform)
    • 6-運用 (Operation)
      • 6-1-稼働時テスト|継続的テスト (Runtime|Continuous-test)
        • 6-1-1-インフラスキャン (Infra-scanning)
          • 6-1-1-1-クラウドリソース (Could-resources)
          • 6-1-1-2-K8S リソース (K8S-resources)
        • 6-1-2-イメージスキャン (Image-scanning)
      • 6-2-侵害と攻撃のシミュレーション (Breach-and-attack-simulation)
      • 6-3-ログ記録と監視 (Logging-and-Monitoring)
      • 6-4-ペンテスト (Pentest)
      • 6-5-脆弱性開示ポリシーとバグバウンティ (VDP|Bug-bounty)
    • 7-ガバナンス (Governance)
      • 7-1-コンプライアンス監査 (Compliance-Auditing)
        • 7-1-1-コンプライアンス監査 (Compliance-Auditing)
        • 7-1-2-Policy as Code (Policy-as-code)
        • 7-1-3-セキュリティベンチマーク (Security-benchmarking)
      • 7-2-データ保護 (Data-protection)
      • 7-3-レポーティング (Reporting)
        • 7-3-1-成熟度追跡 (Tracking-maturities)
        • 7-3-2-脆弱性一元管理ダッシュボード (Central-vulnerability-management-dashboard)
  • V0.1
    • 00. OWASP DevSecOps ガイドラインの概要
      • 00a. DevSecOps 入門
      • 00b. 脅威モデリング
    • 01. コミット前に
      • 01a. シークレットとクレデンシャルに注意
      • 01b. コードのリンティング
    • 02. 脆弱性スキャン
      • 02a. 静的スキャンはプロセスの重要な部分
      • 02b. 動的アプリケーションセキュリティテスト (DAST)
      • 02c. インタラクティブアプリケーションセキュリティテスト
      • 02d. ソフトウェアコンポーネント/コンポジション解析 (SCA)
      • 02e. インフラストラクチャ脆弱性スキャン
      • 02f. コンテナ脆弱性スキャン
      • 02g. プライバシー
      • 02h. 脆弱性の一元管理
    • 03. コンプライアンス監査
Powered by GitBook
On this page
  • シフトレフトセキュリティ戦略とは
  • Dev+Sec+Ops
  • DevSecOps 文化
  • プライバシー
  • ソフトウェアテスト戦略
  • さまざまなソフトウェアテスト戦略
  • テスト手法
  • 参考情報
  1. V0.2
  2. 0-概論 (Intro)

0-2-概要 (Overview)

Previous0-1-序文 (Intro)Next1-導入 (Init)

Last updated 4 months ago

現在、DevOps はあらゆる組織が驚くべき速さで変更を本番環境にデプロイできる力を与えています。 このプロセスでは納品時間が非常に重要な要素であるため、セキュリティ担当者の主な問いは 「このプロセスをどのようにしてセキュアにできるか」もしくは「納品物をどの程度セキュアにするか」となります。 これに関して、DevOps プロセス全体にいくつかのセキュリティ関連のステップを組み込んで、いくつかの自動テストを実行できます。 したがって DevSecOps またはセキュアな DevOps 文化を考慮することで、自社のシフトレフトセキュリティ戦略を推進するのに役立ちます。 少なくとも技術部門では。

シフトレフトセキュリティ戦略とは

簡単に定義すると、シフトレフトセキュリティ戦略は開発プロセスの一環としてセキュリティを組み込む方法またはソリューションで、 アプリケーションやシステムの設計の初期段階からセキュリティを考慮します。 つまり、セキュリティはソフトウェア開発および運用プロセスに携わるすべての人に責任があるということです。 もちろん、セキュリティは専門職であり、セキュリティ関連の役割を担うには高度なスキルを持つ人材が必要です。 しかしこのアプローチでは、設計者、ソフトウェアアーキテクチャ、開発者、DevOps エンジニアなどがセキュリティ担当者とともにセキュリティに関して責任を負います。

Dev+Sec+Ops

互いにカバーするこれらの 3 つのそれぞれの領域がこの図のようなものであると考えると、 つまり上記の言葉の結論として、いくつかのツールを実装し、DevSecOps 文化の促進にも取り組む必要があります。

DevSecOps foundation の創設者である Shannon Lietz は次のように述べています。

DevSecOps の目的と意図は、必要な安全性を犠牲にすることなく、最高レベルのコンテキストを保持する人々にセキュリティ上の決定を迅速かつ大規模に安全に配布することを目標として、「全員がセキュリティに責任を持つ」という考え方に基づいて構築されています。

DevSecOps 文化

前に聞いているように、シフトレフトセキュリティについてお話ししたいと思います。 これは (簡単に定義すると) 設計からセキュリティを考慮すべきだということであり、開発プロセスの早い段階でセキュリティを動かすことを目標としています。

あなたは DevOps チームで働いていて、従来のセキュリティテストを行っているとしましょう。 (それで、すべての QA テストが終了し、本番環境に移行する前に) 何が起こるでしょうか。 そうですね。すべてのバグは早急に修正されなければならず、開発者チームは問題を修正しなければならないというプレッシャーにさらされます。 QA テストを再度実行し、セキュリティテストを再度実行する必要があります。 これはコスト、費用と時間、が増えることを意味します。 最終的には、ビジネスチームが好きではないセキュリティ事象のために軽快さを犠牲にします。

解決策は最終ステップではなくプロセスの早い段階でセキュリティを導入することです。 脅威モデリングで設計時にセキュリティを考慮したり 膨大なセキュリティテストを小規模なセキュリティテストに分割してそれらを開発パイプラインに統合します。

以下の図は DevOps と DevSecOps のライフサイクルの違いを示しています。

プライバシー

GDPR (Europe's General Data Protection Regulations, EU一般データ保護規則)、CCPA (California Consumer Privacy Act, カリフォルニア州消費者プライバシー法)、LGPD (Brazil's Lei Geral de Proteção de Dados, ブラジルの個人情報保護法) などの法規制が世界中で施行されていることから、プライバシーはあらゆる規模の企業にとって主要なトピックになっています。

大量の PII (個人を特定できる情報) を処理するアプリケーションは DevSecOps を採用してプライバシーバイデザインアプローチに従うようにすべきです。このアプローチでは開発プロセスがサイクル全体を通じてプライバシー問題に対処します。

ソフトウェアテスト戦略

テストについて話す際、念頭に置くべきは、 テストにはさまざまな定義があり、それによって セキュアな DevSecOps サイクルを実現するためのルートが変わることです。 この定義を見てみましょう。

さまざまなソフトウェアテスト戦略

  1. ポジティブテスト

ポジティブテストでは、通常の条件と入力の下で、 すべてが期待どおりに動作することを前提としています。 これは有効で関連性のあることのみが発生するという前提で実行されます。 データセットやその他すべての機能は期待どおりとなるでしょう。

  1. ネガティブテスト

ネガティブテストでは想定外の条件下でのシステムの挙動をチェックします。 ネガティブテストは高性能ソフトウェア開発において非常に非常に重要な役割を果たします。 想定外の条件や入力下でのソフトウェアの挙動をチェックします。

テスト手法

  1. 静的テスト

  2. 動的テスト

  3. インタラクティブ解析


参考情報

  1. https://www.geeksforgeeks.org/difference-between-positive-testing-and-negative-testing

  2. https://www.geeksforgeeks.org/difference-between-static-and-dynamic-testing

静的テストはアプリケーションコードを実行せずにソフトウェアの欠陥をチェックします。 障害の原因を見つけやすく簡単に修正できるため、エラーを回避するために開発の初期段階で実行されます。 動的テストでは見つけられない問題でも、静的テストでは簡単に見つけられるものがあります。そのような問題にはハードコードされたクレデンシャル、非推奨の暗号化アルゴリズム、セカンドオーダーインジェクション、脆弱な乱数などがあります。 ほとんどの静的解析ツールではテストスコープが一つのコンポーネントに限定されており、異なるコンポーネント間でのテストを行うことはできません。 (たとえば、マイクロサービスアーキテクチャの場合、静的解析ツールは各マイクロサービスを個別にテストします)

動的テストでは実行時のアプリケーションコードの動作を解析します。スキャナは特別に細工されたリクエストをターゲットアプリケーションに送信します。リクエストパラメータはさまざまな脆弱性を明らかにしようとするため、テスト中に絶えず変更されます。アプリケーションのレスポンスに基づいて、ツールは潜在的な脆弱性を特定し、報告します。静的解析では見つけられない問題でも、動的解析では簡単に検出できるものがあります。そのような問題には認証やセッションの問題、平文で送信される機密データなどのクライアント側の脆弱性があります。 動的解析ツールはアプリケーションフロー全体を (複数コンポーネントを同時に) テストできる可能性があります。 (たとえば、マイクロサービスアーキテクチャの場合、動的解析ツールは一つのマイクロサービスを指定することができますが、それらが相互に作用するため結果はアプリケーション全体の動作を表します)

インタラクティブアプリケーションセキュリティテスト (IAST) とも呼ばれ、他のシステムがアプリケーションと相互連携する際にアプリケーションを監視し、脆弱性を観察します。これはアプリケーションでデプロイされるセンサーやエージェントによって実現されます。センサーは HTTP リクエストから、実行されたコードまでフロー全体を見て、アプリケーションを介してデータを追跡します。静的解析と同様に、一度に一つのコンポーネントをテストできますが、複数のコンポーネントはできません。ただし、エージェントやセンサーがすべてのコンポーネントにデプロイされている場合、それらが相互連携するとアプリケーションで使用される各コンポーネントの脆弱性が明らかになる可能性があります。 (たとえば、マイクロサービスアーキテクチャの場合、エージェントやセンサーが接続されているマイクロサービスのみが脆弱性を報告します)