モバイルアプリケーションのセキュリティテスト

以下のセクションでは一般的なセキュリティテストの原則と重要な用語について概要を簡単に説明します。紹介する概念は他のタイプのペネトレーションテストで見られるものとほぼ同じです。そのため、経験豊富なテスト技術者であればコンテンツの一部に精通しているかもしれません。

このガイドでは、静的解析や動的解析によるモバイルアプリのセキュリティを評価するための包括的なフレーズとして「モバイルアプリのセキュリティテスト」を使用します。セキュリティ業界では「モバイルアプリのペネトレーションテスト」や「モバイルアプリのセキュリティレビュー」などの用語が一貫性なく使用されていますが、これらの用語はほぼ同じことを指しています。モバイルアプリのセキュリティテストは一般的に、クライアントサーバーアーキテクチャとモバイルアプリにより使用されるサーバーサイド API を包括する、より大きなセキュリティ評価やペネトレーションテストの一部です。

このガイドでは、二つのコンテキストでのモバイルアプリのセキュリティテストを扱います。ひとつは開発ライフサイクルの終わり近くに完了する「古典的な」セキュリティテストです。このコンテキストでは、テスト担当者が最終版に近いバージョンのアプリまたは出荷準備バージョンのアプリにアクセスし、セキュリティの問題を特定し、(通常は壊滅的な) レポートを作成します。もうひとつのコンテキストはソフトウェア開発ライフサイクルの初めからの要件の実装とセキュリティテストの自動化が特徴です。どちらのコンテキストにも同じ基本要件とテストケースが適用されますが、上位レベルの方法論およびクライアントとの対話のレベルに違いがあります。

テストの原則

ホワイトボックステストとブラックボックステスト

概念を定義することから始めましょう。

  • ブラックボックステスト はテスト対象のアプリに関する情報をテスト担当者が取得することなく実行されます。このプロセスは「ゼロ知識テスト」と呼ばれることもあります。このテストの主な目的は、テスト担当者が公に入手可能で発見可能な情報の可能な用途を模索するという意味で、実際の攻撃者のように振る舞うことです。

  • ホワイトボックステスト (「完全知識テスト」とも呼ばれることもあります) は、テスト担当者がアプリの完全な知識を持つという意味でブラックボックステストとは正反対です。知識にはソースコード、ドキュメント、図を含みます。このアプローチはブラックボックステストよりもはるかに高速なテストを可能にします。透明性があり、追加の知識が得られることでテスト担当者はより洗練されたきめ細かいテストケースを構築できます。

  • グレーボックステスト は前述の二つのテストタイプの間にあるすべてのテストです。テスト担当者には一部の情報が提供されます (通常は資格情報のみ) 。その他の情報は発見されることを志します。このタイプのテストは、テストケースの数、テストのコスト、スピード、スコープにおいて興味深い妥協点です。グレーボックステストはセキュリティ業界で最も一般的な種類のテストです。

できるだけ効率的にテスト時間を使用できるようにするため、ソースコードを要求することを強くお勧めします。テスト担当者のコードアクセスはまったく外部攻撃をシミュレートしませんが、テスト担当者がコードレベルで識別されたすべての異常や疑わしい動作を検証できるようにすることで、脆弱性の特定を簡略化します。ホワイトボックステストはアプリが以前にテストされていない場合に進むべき道です。

Android での逆コンパイルは簡単ですが、そのソースコードは難読化されている可能性があり、逆難読化には時間がかかります。したがってテスト担当者がソースコードにアクセスするもうひとつの理由は時間の節約です。

脆弱性解析

脆弱性解析は一般的にアプリ内の脆弱性を探すプロセスです。これは手動で行うこともできますが、主に自動スキャナを使用して主要な脆弱性を識別します。静的解析および動的解析は脆弱性解析の一種です。

静的解析と動的解析

静的アプリケーションセキュリティテスト (SAST) ではソースコードを手動または自動で解析することにより、アプリのコンポーネントを実行せずに検査します。 OWASP は 静的コード解析 に関する情報を提供しており、技法、長所、短所、制限を理解するのに役立ちます。

動的アプリケーションセキュリティテスト (DAST) では実行時にアプリを検査します。このタイプの解析は手動または自動で行うことができます。通常、これは静的解析により提供される情報を提供することはありませんが、ユーザーの観点から興味深い要素 (資産、機能、エントリポイントなど) を検出のに適した方法です。

静的解析と動的解析を定義しましたので、より深く掘り下げてみましょう。

静的解析

静的解析の中で、モバイルアプリのソースコードはレビューされ、セキュリティコントロールが適切に実装されていることを確認します。ほとんどの場合、自動と手動のハイブリッドなアプローチが使用されます。自動スキャンでは「低い位置にぶら下がった果実」 (訳注：「簡単に解決できる問題」の比喩) を取得し、ヒトのテスト担当者は特定の使用状況を念頭においてコードベースを探索します。

手動コードレビュー

テスト担当者はモバイルアプリのソースコードをセキュリティ脆弱性について手動で解析することにより、手動コードレビューを実施します。手法には 'grep' コマンドでの基本的なキーワード検索からソースコードの行単位の調査にまで多岐にわたります。IDE (統合開発環境) は基本的なコードレビュー機能を提供することが多く、さまざまなツールで拡張できます。

手動コード解析の一般的なアプローチでは、"executeStatement" や "executeQuery" などのデータベース関連のメソッド呼び出しなど、特定の API やキーワードを検索して、主要なセキュリティ脆弱性の指標を識別します。これらの文字列を含むコードは手動解析の開始点として適しています。

自動コード解析とは対照的に、特にコードが技術的にセキュアであるが論理的に欠陥がある場合、手動コードレビューはビジネスロジックの脆弱性、標準規約違反、設計上の欠陥を識別するのに非常に適しています。このようなシナリオは自動コード解析ツールではほとんど検出されません。

手動コードレビューにはモバイルアプリに使用される言語とフレームワークの両方に精通した専門のコードレビュー担当者が必要です。特に多くの依存関係を持つ大きなコードベースを与えられた場合、レビュー担当者にとって完全なコードレビューは時間がかかり、退屈で、手間のかかるプロセスになります。

自動ソースコード解析

自動解析ツールを使用すると、静的アプリケーションセキュリティテスト (SAST) のレビュープロセスを高速化できます。ソースコードがあらかじめ定義された一連のルールや業界のベストプラクティスに準拠しているかどうかを確認し、通常、検出結果の一覧や検出されたすべての違反の警告とフラグを表示します。一部の静的解析ツールはコンパイルされたアプリに対してのみ実行し、一部は元のソースコードを入力する必要があり、また一部は統合開発環境 (IDE) でライブ解析プラグインとして実行します。

一部の静的解析ツールにはモバイルアプリを解析するために必要なルールやセマンティックに関する多くの情報が組み込まれていますが、特にターゲット環境用に構成されていない場合には、多くの誤検知が発生する可能性があります。したがって、セキュリティ専門家は常に結果をレビューする必要があります。

"テストツール" の章には静的解析ツールのリストがあります。これはこの本の最後にあります。

動的解析

DAST の焦点はリアルタイム実行によるアプリのテストと評価です。動的解析の主な目的はプログラムを実行する中でセキュリティ上の脆弱性や弱点を見つけることです。動的解析はモバイルプラットフォームレイヤとバックエンドサービスや API の両方で実行され、モバイルアプリのリクエストやレスポンスパターンを解析します。

動的解析は、通常、転送時のデータの開示、認証および認可の問題、サーバーの構成エラーなど、よくあるタイプの攻撃に対して十分な保護を提供するセキュリティメカニズムをチェックするために使用されます。

誤検知の回避

自動スキャンツール

自動テストツールはアプリコンテキストに対する感度の欠如が課題です。これらのツールは見当違いのものを潜在的な問題と識別することがあります。そのような結果を「誤検知」と呼びます。

例えば、セキュリティテスト担当者は一般的にウェブブラウザで悪用可能ですが、モバイルアプリには関係しない脆弱性を報告します。この誤検知は、バックエンドサービスをスキャンするために使用する自動ツールが、通常のブラウザベースのウェブアプリをベースにしているために発生します。 CSRF (クロスサイトリクエストフォージェリ) やクロスサイトスクリプティング (XSS) などの問題がそれに応じて報告されます。

CSRF を例にしましょう。CSRF 攻撃が成功するには以下が必要です。

  • ログインユーザーにウェブブラウザで悪意のあるリンクを開くように誘導する機能。脆弱なサイトにアクセスするために使用されます。

  • クライアント (ブラウザ) はリクエストにセッションクッキーやその他の認証トークンを自動的に追加する必要があります。

モバイルアプリがこれらの要件を満たしていません。WebView とクッキーベースのセッション管理を使用されていても、ユーザーがクリックした悪意のあるリンクは別のクッキーストアを持つデフォルトブラウザで開きます。

アプリが WebView を含む場合、蓄積型クロスサイトスクリプティング (XSS) が問題になることがあります。また、アプリが JavaScript インタフェースをエクスポートする場合、コマンド実行につながることもあります。しかし、反射型クロスサイトスクリプティングは上記の理由により問題になることはほとんどありません (それらが存在するかどうかは議論の余地がありますが、出力のエスケープは単なるベストプラクティスです) 。

いずれの場合でも、リスク評価を実施する際には悪用シナリオを検討します。スキャンツールの出力を盲目的に信頼してはいけません。

ペネトレーションテスト (通称ペンテスト)

従来のアプローチでは、開発プロセスの最後に利用可能なビルドなど、アプリの最終ビルドまたは終盤間近のビルドの総合的なセキュリティテストを行います。開発プロセスの最後でのテストには モバイルアプリセキュリティ検証標準 (MASVS) および関連するチェックリストをテストのベースラインとして推奨します。典型的なセキュリティテストは以下のように構成されます。

  • 準備 - 適用可能なセキュリティコントロール、組織のテスト目標、機密データの特定など、セキュリティテストのスコープを定義します。より一般的には、準備にはクライアントとのすべての同期と、テスト担当者 (多くの場合サードパーティ) の法的保護が含まれます。書面による許諾なしにシステムを攻撃することは、世界の多くの地域で違法であることを忘れないでください。

  • 情報収集 - アプリの 環境 および アーキテクチャ のコンテキストを分析して、一般的なコンテキストの理解を得ます。

  • アプリケーションのマッピング - 前のフェーズの情報に基づいています。アプリの自動スキャンと手動探索で補完されることがあります。マッピングによりアプリ、そのエントリポイント、それが保持するデータ、および潜在的な主な脆弱性を十分に理解できます。これらの脆弱性はそれらの悪用が引き起こす被害に応じてランク付けされ、セキュリティテスト担当者はそれらに優先順位付けします。このフェーズにはテスト実行時に使用されるテストケースの作成が含まれます。

  • エクスプロイト - このフェーズでは、セキュリティテスト担当者は前のフェーズで特定された脆弱性を利用してアプリに侵入を試みます。このフェーズは脆弱性が実際に有効なものであるかどうかを判断するために必要です。

  • 報告 - クライアントにとって重要なこのフェーズでは、セキュリティテスト担当者は脆弱性を報告します。これには悪用プロセスの詳細、脆弱性の種類の分類、攻撃者がターゲットを危殆化できる場合のリスクの文書化、テスト担当者が不正にアクセスできたデータの概要が含まれます。

準備

アプリをテストするためのセキュリティレベルはテストを行う前に決定する必要があります。セキュリティ要件はプロジェクトの開始時に決定すべきです。組織ごとにセキュリティニーズが異なり、テスト活動に投じることができるリソースも異なります。MASVS Level 1 (L1) のコントロールはすべてのモバイルアプリに適用できますが、テクニカルステークホルダおよびビジネスステークホルダが L1 および Level 2 (L2) MASVS コントロールのチェックリスト全体をウォークスルーすることが、テストカバレッジのレベルを決定する良い方法です。

組織によっては特定の地域でさまざまな規制や法的義務を負う可能性があります。アプリが機密データを処理しない場合でも、(業界の規制や現地の法律により) 一部の L2 要件が関連することがあります。例えば、二要素認証 (2FA) は金融アプリに対して義務付けられ、各国の中央銀行や金融監督庁により強制されることがあります。

開発プロセスの初期段階で定義されるセキュリティの目標やコントロールはステークホルダとのディスカッションの中で見直されることもあります。コントロールの中には MASVS コントロールに従うものもあれば、組織やアプリに固有のものもあります。

すべてのセキュリティテストのベースラインを定義するため、すべての関係者は決定事項とチェックリストのスコープに合意する必要があります。

クライアントとの調整

作業テスト環境をセットアップすることは困難なタスクです。例えば、エンタープライズワイヤレスアクセスポイントおよびネットワークの制限によりクライアント施設で実行される動的解析が妨げられることがあります。会社のポリシーではエンタープライズネットワーク内でのルート化電話や (ハードウェアおよびソフトウェア) ネットワークテストツールの使用を禁止することがあります。ルート検出やその他のリバースエンジニアリング対策を実装するアプリではさらなる解析に必要な作業を大幅に増やす可能性があります。

セキュリティテストにはモバイルアプリのネットワークトラフィックの監視と操作、アプリデータファイルの検査、API コールの計測など多くの侵襲的なタスクが含まれます。証明書ピンニングやルート検出などのセキュリティコントロールはこれらのタスクを妨げ、テストを大幅にスローダウンさせる可能性があります。

これらの障害を克服するために、開発チームに二つのアプリのビルドバリアントを要求することができます。一つ目のバリアントはリリースビルドにすべきです。実装されたコントロールが適切に機能しており簡単にバイパスできないかどうかを判断できるようにするためです。二つ目のバリアントはデバッグビルドにすべきです。特定のセキュリティコントロールを非アクティブ化したものです。二つの異なるビルドをテストすることがすべてのテストケースをカバーする最も効率的な方法です。

エンゲージメントのスコープによっては、このアプローチは可能ではないかもしれません。ホワイトボックステスト用にプロダクションビルドとデバックビルドの両方を要求することで、すべてのテストケースを完了しアプリのセキュリティ成熟度を明確に述べるのに役立ちます。クライアントはブラックボックステストがプロダクションアプリとそのセキュリティコントロールの有効性の評価にフォーカスすることを好む場合があります。

両方のタイプのテストのスコープは準備フェーズで議論すべきです。例えば、セキュリティコントロールを調整すべきかどうかはテスト前に決定すべきです。追加のトピックについては以下で説明します。

機密データの特定

機密情報の分類は業界や国によって異なります。さらに、組織は機密データを制限して表示する場合があり、機密情報を明確に区別するデータ分類ポリシーを持つ場合があります。

データにアクセスできる一般的な状態は三つあります。

  • 保存時 - データがファイルやデータストアに保存されているとき

  • 使用時 - アプリがアドレス空間にデータをロードしたとき

  • 転送時 - モバイルアプリとエンドポイント間でデータが交換されたときや、デバイス上のプロセスを使用するとき、例、IPC (プロセス間通信) 時など

それぞれの状態に適した調査の度合いはデータの重要度やアクセスの可能性に依存します。例えば、攻撃者はウェブサーバーよりもモバイルデバイスに物理的にアクセスする可能性が高いため、アプリメモリに保持されているデータはコアダンプ経由でアクセスされるウェブサーバー上のデータよりも脆弱になります。

利用可能なデータ分類ポリシーがない場合、一般的に機密とみなされる以下のリストの情報を使用します。

  • ユーザー認証情報 (資格情報、PIN など)

  • 個人情報の盗難により悪用される可能性のある個人識別情報 (PII) : 社会保障番号、クレジットカード番号、銀行口座番号、健康保険情報

  • 人を識別する可能性のあるデバイス識別子

  • 侵害された場合、風評被害や金銭的なコストにつながる機密性の高いデータ

  • 保護が法的義務であるデータ

  • アプリ (またはそれに関連するシステム) により生成され、他のデータやシステムを保護するために使用される技術データ (暗号化鍵など)

「機密データ」の定義はテストを開始する前に決定する必要があります。定義なしでは機密データの漏洩を検出することが不可能なことがあるためです。

情報収集

情報収集にはアプリのアーキテクチャ、アプリが提供するビジネスユースケース、アプリが動作するコンテキストについての情報の収集が含まれます。そのような情報は「環境」と「アーキテクチャ」に大別できます。

環境情報

環境情報には以下が含まれます。

  • アプリのための組織の目標。機能はアプリとのユーザーの対話を形成し、一部の領域では他よりも攻撃者がターゲットにする可能性が高くなります。

  • 関連業界。業界によってリスクプロファイルが異なる場合があります。

  • ステークホルダと投資家。アプリに興味を持っているのは誰か、責任を負うのは誰かを理解します。

  • 内部プロセス、ワークフロー、および組織構造。組織固有の内部プロセスおよびワークフローは ビジネスロジック脆弱性 の機会を生み出す可能性があります。

アーキテクチャ情報

アーキテクチャ情報には以下が含まれます。

  • モバイルアプリ: アプリがデータにアクセスしそれをプロセス内で管理する方法、他のリソースとの通信方法、ユーザーセッションの管理方法、脱獄済み電話やルート化された電話上で実行していることを検出してこれらの状況に反応するかどうか。

  • オペレーティングシステム: アプリが実行されるオペレーティングシステムと OS バージョン (Android または iOS のバージョン制限を含む) 、アプリがモバイルデバイス管理 (MDM) コントロールを備えたデバイス上で動作することが期待されているかどうか、および関連する OS 脆弱性。

  • ネットワーク: セキュアなトランスポートプロトコル (TLS など) の使用、強力な鍵および暗号アルゴリズム (SHA-2 など) の使用によるネットワークトラフィック暗号化の保護、証明書ピンニングの使用によるエンドポイントの検証、など。

  • リモートサービス: アプリが使用するリモートサービスと、それらが侵害された場合にクライアントは侵害される可能性があるかどうか。

アプリケーションのマッピング

セキュリティテスト担当者がアプリとそのコンテキストに関する情報を取得したら、次のステップはアプリの構造とコンテンツをマッピングすることです。例えば、エントリポイント、機能、データを特定します。

ホワイトボックスまたはグレーボックスのパラダイムでペネトレーションテストを実行する場合、プロジェクトの内部からのドキュメント (アーキテクチャ図、機能仕様、コードなど) がそのプロセスを大幅に促進する可能性があります。ソースコードが利用可能な場合、SAST ツールを使用すると脆弱性 (SQL インジェクションなど) に関する貴重な情報が明らかになります。 DAST ツールはブラックボックステストをサポートしアプリを自動的にスキャンします。テスト担当者は数時間ないし数日を必要としますが、スキャナは同じタスクを数分で実行できます。但し、自動ツールには制限があり、検出するようにプログラムされたもののみを検出することに注意します。したがって、自動ツールからの結果を増やすには人間の解析が必要になることがあります (多くの場合には直感がセキュリティテストの鍵となります) 。

脅威モデリングは重要な成果物です。通常、ワークショップからのドキュメントはセキュリティテスト担当者が必要とする情報 (エントリポイント、資産、脆弱性、重要度など) の識別を大いにサポートします。テスト担当者はそのようなドキュメントの入手可能性についてクライアントと話し合うことを強く推奨します。脅威モデリングはソフトウェア開発ライフサイクルの主要パートであるべきです。通常、プロジェクトの初期フェーズで発生します。

OWASP で定義されている脅威モデリングガイドライン は一般的にモバイルアプリに適用できます。

エクスプロイト

残念ながら、時間や金銭的な制約により多くのペンテストは自動スキャナ (脆弱性解析用など) を介したアプリケーションマッピングに制限されています。前のフェーズで特定された脆弱性は興味深いかもしれませんが、五つの軸に関してその関連性を確認する必要があります。

  • 損害の可能性 (Damage potential) - 脆弱性の悪用から生じる可能性のある損害

  • 再現可能性 (Reproducibility) - 攻撃の再現の容易さ

  • 悪用可能性 (Exploitability) - 攻撃の実行の容易さ

  • 影響を受けるユーザー (Affected users) - 攻撃により影響を受けるユーザーの数

  • 発見可能性 (Discoverability) - 脆弱性の発見の容易さ

すべての可能性に対して、一部の脆弱性は悪用可能ではないかもしれませんし、軽微な侵害があればそれをもたらす可能性もあります。ある脆弱性は一見無害に見えるかもしれませんが、現実的なテスト条件下では非常に危険であると判断されることもあります。エクスプロイトフェーズを慎重に行うテスト担当者は脆弱性とその影響を特徴付けることによりペンテストをサポートします。

報告

セキュリティテスト担当者の調査結果は明確にドキュメント化されている場合にのみクライアントにとって価値があります。適切なペンテストレポートには以下のような情報が含まれますが、これらに限定されません。

  • エグゼクティブサマリー

  • スコープとコンテキストの説明 (対象システムなど)

  • 使用される手法

  • 情報源 (クライアントから提供されるか、ペンテスト中に発見されるか)

  • 優先順位付けされた調査結果 (DREAD 分類により構造化された脆弱性など)

  • 詳細な調査結果

  • それぞれの欠陥を修正するための推奨事項

多くのペンテストレポートテンプレートがインターネットで入手できます。Google はあなたの友達です。

セキュリティテストと SDLC

セキュリティテストの原則は近年の歴史の中で基本的には変化していませんが、ソフトウェア開発技法は劇的に変化しています。アジャイルプラクティスが広く採用されたことでソフトウェア開発はスピードアップしましたが、信頼性の高いソフトウェアを提供し続ける中でセキュリティテスト担当者はより迅速かつ俊敏になる必要がありました。

以下のセクションではこの進化にフォーカスし、最新のセキュリティテストについて説明します。

ソフトウェア開発ライフサイクル内でのセキュリティテスト

結局のところ、ソフトウェア開発はそれほど古くはないため、フレームワークなしでの開発の終焉は容易に観察できます。私たちは皆、ソースコードが大きくなるにつれて作業を制御するために最小限のルールセットの必要性を経験しています。

過去には、「ウォーターフォール」方法論が最も広く採用されていました。開発はあらかじめ定義されたシーケンスを持つステップで進められました。単一のステップに限定されたバックトラッキング機能はウォーターフォール方法論の重大な欠点でした。それらには重要な肯定的特徴 (構造を提供すること、テスト担当者が労力を必要とする箇所を明確にすることを助けること、明確で理解しやすいこと、など) がありますが、否定的なもの (部門が縦割り型になること、遅くなること、チームが専門特化すること、など) もあります。

ソフトウェア開発が成熟するにつれて、競争が激化し、開発者はより少ない予算でソフトウェア製品を作成しながら市場の変化により迅速に対応する必要がありました。より少ない構造という考え方が一般的になり、小規模なチームが協力して、組織全体の部門の壁を打ち破りました。「アジャイル」コンセプトが生まれました (Scrum, XP, RAD はアジャイル実装のよく知られた例です) 。より自律的なチームがより迅速に連携できるようになりました。

セキュリティはもともとソフトウェア開発に不可欠な部分ではありませんでした。それは後付けであり、不十分なソフトウェアセキュリティを補う必要がある運用チームによりネットワークレベルで実行されていました。ソフトウェアプログラムが境界線内にある場合、統合されていないセキュリティが可能でしたが、ウェブ、モバイル、および IoT テクノロジーを伴う新しい種類のソフトウェア消費によりこの概念は時代遅れになりました。現在、脆弱性の補填は非常に難しいことが多いため、セキュリティはソフトウェアの 内部で 焼き固める必要があります。

"SDLC" は以下のセクションではセキュリティがソフトウェア開発プロセスの一部であるという考えを具体化するのに役立つ "Secure SDLC" と同じ意味で使用されます。同じ精神で、DevSecOps という名前を使用して、セキュリティが DevOps の一部であるという事実を強調しています。

SDLC の概要

SDLC の一般的な説明

SDLC は常に同じステップで構成されます (プロセス全体はウォーターフォールパラダイムでは連続的であり、アジャイルパラダイムでは反復的です) 。

  • アプリとそのコンポーネントの リスク評価 を実行してリスクプロファイルを特定します。これらのリスクプロファイルは一般的に組織のリスクアペタイトと適用される規制要件に依存します。リスク評価はインターネットを介してアプリにアクセス可能かどうかや、アプリが処理および保存するデータの種類などの要因にも基づいています。財務、市場、業界などのあらゆる種類のリスクを考慮する必要があります。データ分類ポリシーでは機密性の高いデータとその保護方法を指定します。

  • セキュリティ要件 は機能要件が収集される際、プロジェクトまたは開発サイクルの開始時に決定されます。ユースケースが作成されると 悪用ケース が追加されます。チーム (開発チームを含む) には必要に応じてセキュリティトレーニング (セキュアコーディングなど) が提供されることがあります。 OWASP MASVS を使用し、リスク評価フェーズに基づいてモバイルアプリのセキュリティ要件を決定します。特にアジャイルプロジェクトでは、機能とデータクラスが追加された際には要件をレビューすることを繰り返すことが一般的です。

  • 脅威モデリング は基本的に脅威の識別、列挙、優先順位付け、および初期処理であり、アーキテクチャ開発および設計の過程として実行する必要がある基本的な成果物です。セキュリティアーキテクチャ は脅威モデルの要素であり、脅威モデリングフェーズの後に (ソフトウェアとハードウェアの両面で) 洗練されます。セキュアコーディングルール が確立され、使用される セキュリティツール のリストが作成されます。セキュリティテスト の戦略が明確になります。

  • セキュリティ要件および設計上の考慮事項はすべて、アプリケーションライフサイクル管理 (ALM) システム (イシュートラッカーとしても知られています) に保存すべきです。開発チームや運用チームが開発ワークフローへのセキュリティ要件の緊密な統合を確実にするために使用します。開発者がすばやく参照できるように、セキュリティ要件には関連するソースコードスニペットを含めるべきです。バージョン管理のものでこれらのコードスニペットのみを含む専用リポジトリを作成することは、従来のアプローチ (ワードドキュメントや PDF にガイドラインを保存すること) よりも有益なセキュアコーディング戦略です。

  • セキュアなソフトウェア開発。コードセキュリティを強化するには、セキュリティコードレビュー、静的アプリケーションセキュリティテスト、セキュリティユニットテスト などのアクティビティを完了する必要があります。これらのセキュリティアクティビティと似たようなものが存在しますが、同じロジックをセキュリティに適用する必要があります。例、セキュリティ欠陥 (例えば、入力妥当性確認の欠落、全リソース解放の失敗など) に対するコードのレビュー、解析、テストなど。

  • 次に待望のリリース候補ビルドテストがあります。手動および自動の両方での ペネトレーションテスト (「ペンテスト」) です。動的アプリケーションセキュリティテスト は一般的にこのフェーズでも実行されます。

  • すべてのステークホルダによる 受け入れ でソフトウェアが 認定 された後、運用 チームに安全に移行し本稼働に入ります。

  • 無視されがちな最後のフェーズは使用終了後のソフトウェアの安全な 廃止措置 です。

以下の図はすべてのフェーズと成果物を示しています。

プロジェクトの一般的なリスクプロファイルに基づいて、一部の成果物を単純化 (またはスキップ) し、他の成果物 (公式な中間承認、特定ポイントの公式な文書化など) を追加できます。 常に二つのことを覚えておいてください。SDLC はソフトウェア開発に関連するリスクを軽減することを目的としています。また、SDLC はそのためのコントロールをセットアップするのに役立つフレームワークです。 これは SDLC の一般的な説明です。このフレームワークは常にプロジェクトに合わせて調整してください。

テスト戦略の定義

テスト戦略では SDLC の中で実行されるテストとテスト頻度を指定します。テスト戦略は最終的なソフトウェア製品がセキュリティ目標を満たしていることを確認するために使用されます。セキュリティ目標は一般的にクライアントの法務、マーケティング、経営陣により決定されます。 テスト戦略は一般的にセキュア設定フェーズで作成されます。リスクが明らかになった後 (開始フェーズ内) であり、コード開発 (セキュア実装フェーズ) が始まる前です。この戦略にはリスク管理、以前の脅威モデリング、セキュリティエンジニアリングなどのアクティビティからの入力が必要です。

テスト戦略を公式に記述する必要はありません。ストーリーで記述したり (アジャイルプロジェクトの場合) 、チェックリストですばやく列挙したり、特定ツールでのテストケースとして指定したりできます。但し、戦略は必ず共有する必要があります。それを定義したチーム以外のチームにより実行される必要があるためです。さらに、いずれにも容認できない負担がかからないようにするために、すべての技術チームがそれに同意する必要があります。

テスト戦略では以下のようなトピックを扱います。

  • 目標およびリスクの説明

  • 目標達成のための計画、リスク軽減、どのテストが必須か、誰がそれらを実行するか、いつどのように実行されるか

  • 受け入れ基準

テスト戦略の進捗と有効性を追跡するには、メトリクスを定義し、プロジェクトの中で継続的に更新し、定期的に伝達すべきです。関連するメトリクスの選択に関してはその本全体を書くことになってしまいます。ここで言えることは、それらはリスクプロファイル、プロジェクト、および組織に依存しているということです。メトリクスの例には以下のものがあります。

  • 正常に実装されたセキュリティコントロールに関連するストーリーの数

  • セキュリティコントロールと機密性の高い機能のユニットテストに対するコードカバレッジ

  • 静的解析ツールを介してビルドごとに見つかったセキュリティバグの数

  • セキュリティバグバックログの傾向 (緊急度によりソートされる場合があります)

これらは一例であり、他のメトリクスがプロジェクトにより関連することがあります。メトリクスはプロジェクトを管理下に置くための強力なツールであり、プロジェクトマネージャは何が起こっていて何を改善する必要があるのかを明確かつ総合的に把握できます。

内部チームが実行したテストと独立した第三者が実行したテストを区別することが重要です。内部テストは一般的に日常業務の改善に役立ちますが、第三者テストは組織全体にとってより有益です。内部テストは非常に頻繁に実行できますが、第三者テストは多くても年に一度か二度です。また、前者は後者よりも安価です。 両者が必要であり、多くの規制は独立した第三者からのテストを義務付けています。そのようなテストがより信頼できるためです。

ウォーターフォールでのセキュリティテスト

ウォーターフォールとは何でありテストアクティビティをどのようにアレンジするか

基本的に、SDLC は何かしらの開発ライフサイクルの使用を強制するものではありません。どのような状況でもセキュリティに対処できる (そしてしなければならない) と言って差し支えありません。

ウォーターフォール方法論は21世紀以前には一般的でした。もっとも有名な応用は「V モデル」と呼ばれ、フェーズが順番に実行され、一つのステップのみがバックトラックできます。 このモデルのテストアクティビティは順番に発生し、ほとんどの場合、アプリ開発の大部分が完了したライフサイクルの時点で全体として実行されます。このアクティビティシーケンスではプロジェクトの開始時に設定されたアーキテクチャやその他の要素を変更することはほとんど不可能であることを意味します。たとえ欠陥が特定された後にコードを変更されるとしてもです。

Agile/DevOps および DevSecOps におけるセキュリティテスト

DevOps はソフトウェア開発 (一般に Devs と呼ばれる) と運用 (一般に Ops と呼ばれる) に関与するすべてのステークホルダの間の密接なコミュニケーションにフォーカスしたプラクティスを指します。DevOps は Devs と Ops を統合することではありません。 開発チームと運用チームはもともと縦割り型で作業していましたが、開発されたソフトウェアを本稼働するのにかなりの時間がかかる場合がありました。開発チームがアジャイルで作業してより多くの配信を本稼働に移行する必要が生じた際に、運用チームはそのペースに合わせてスピードアップする必要がありました。DevOps はソフトウェアをより迅速にユーザーへリリースできるという点で、この課題に対するソリューションの必要な進化です。これは広範なビルド自動化、ソフトウェアテストおよびリリースのプロセス、およびインフラストラクチャの変更 (DevOps のコラボレーションの側面に加えて) によって大部分が達成されます。この自動化は継続的インテグレーションと継続的デリバリー (CI/CD) の概念を備えたデプロイメントパイプラインに組み込まれています。

"DevOps" という用語は開発チームと運用チームの間のコラボレーションのみを表していると思われるかもしれませんが、DevOps についてリーダーの Gene Kim が次のように発言しています。「一見したところ、その問題は Devs と Ops の間にあるように見えるかもしれませんが、そこにはテストがあり、情報セキュリティの目標があり、システムとデータを保護する必要があります。これらは経営における最上位の重要事項であり、DevOps 全体像の一部となっています。」

言い換えると、DevOps コラボレーションには品質チーム、セキュリティチーム、およびプロジェクトに関連する他の多くのチームが含まれます。今日 "DevOps" を耳にしたら、あなたはおそらく DevOpsQATestInfoSec のようなものを考えるべきです。実際、DevOps の価値はスピードだけではなく、品質、セキュリティ、信頼性、安定性、および耐性の向上にも関係しています。

セキュリティはアプリの全体的な品質、パフォーマンス、使いやすさと同様にビジネスの成功にとっても重要です。開発サイクルが短縮され、デリバリー頻度が増加するにつれて、品質とセキュリティが最初から組み込まれていることが不可欠になります。DevSecOps は DevOps プロセスにセキュリティを追加することに関するすべてです。ほとんどの欠陥は本稼働中に特定されます。DevOps は多くの欠陥をライフサイクルの早い段階で特定し、リリースされたアプリの欠陥数を最小限に抑えるためのベストプラクティスを明示します。

ただし、DevSecOps は最高となるソフトウェアを運用に提供することを目的とした単なる線形プロセスではありません。運用は本稼働中のソフトウェアを綿密に監視して問題を特定し、開発と迅速かつ効率的なフィードバックループを形成することで問題を修正することも義務付けられています。DevSecOps は継続的改善を重視するプロセスです。

この主張の人間的な側面はビジネス成果を達成するために協力する部門横断的チームの作成に反映されます。このセクションでは必要な連携とセキュリティを開発ライフサイクル (プロジェクトの開始時点からユーザーへの価値の提供終了まで) に統合することにフォーカスしています。

アジャイルおよび DevSecOps は何でありテストアクティビティをどのようにアレンジするか

概要

自動化は DevSecOps の重要なプラクティスです。前述のように、開発から運用までのデリバリーの頻度は従来のアプローチと比較して増加しており、通常は時間がかかるアクティビティを維持する必要があります。たとえば、より短い時間で同様の付加価値を提供します。その結果、非生産的なアクティビティを放棄しなければならず、重要なタスクを固定しなければなりません。これらの変更はインフラストラクチャの変更、デプロイメント、およびセキュリティに影響を及ぼします。

  • インフラストラクチャは Infrastructure as Code として実装されます

  • デプロイメントは 継続的インテグレーション および 継続的デリバリー の概念を通じて、よりスクリプト化され翻訳されます

  • セキュリティアクティビティ は可能な限り自動化され、ライフサイクル全体で行われます

以下のセクションではこれら三つのポイントについて詳しく説明します。

Infrastructure as Code

コンピューティングリソース (物理サーバー、仮想マシンなど) を手動でプロビジョニングして構成ファイルを変更する代わりに、Infrastructure as Code はツールと使用してプロビジョニングプロセスを高速化するために自動化し、信頼性と再現性を高めます。当該スクリプトは共有と問題解決を容易にするためにバージョンコントロールのもとに保管されることがよくあります。

Infrastructure as Code プラクティスは開発チームと運用チーム間のコラボレーションを促進し、以下の結果が得られます。

  • Devs は精通した視点でインフラストラクチャをよりよく理解し、実行中のアプリに必要なリソースを準備できます。

  • Ops はそのアプリにより適した環境を運用し、Devs と言葉を共有します。

また、Infrastructure as Code は 開発 ("DEV"), 統合 ("INT"), テスト ("PPR"), 実稼働 ("PRD") のために、従来のソフトウェア作成プロジェクトに必要な環境の構築も容易にします。(Pre-Production - 通常、一部のテストは早期の環境で実行され、PPR テストは主に非回帰およびパフォーマンスに関連し、データは実稼働で使用されるデータ同様です。) Infrastructure as Code の価値は環境間で考えられる類似性にあります (それらは同じであるべきです) 。

Infrastructure as Code は一般的にクラウドベースのリソースを持つプロジェクトに使用されます。多くのベンダーがプロビジョニングアイテム (仮想マシン、ストレージスペースなど) および構成作業 (例、仮想マシンが使用するメモリサイズや CPU 数を変更すること) に使用できる API を提供しているためです。これらの API は管理者が監視コンソールからこれらのアクティビティを実行する代わりのものを提供します。

このドメインの主なツールには Puppet, Terraform, Packer, Chef および Ansible があります。

デプロイメント

デプロイメントパイプラインの洗練度はプロジェクト組織や開発チームの成熟度に依存します。最もシンプルな形式では、デプロイメントパイプラインはコミットフェーズで構成されます。コミットフェーズには一般的にシンプルなコンパイラチェックとユニットテストスイートの実行、およびデプロイ可能なアプリのアーティファクトの作成が含まれます。リリース候補はバージョン管理システムのトランクにチェックインされた最新バージョンです。リリース候補は本稼働へのデプロイメントのために満たす必要がある標準への適合についてデプロイメントパイプラインにより評価されます。

コミットフェーズは開発者に即座にフィードバックを提供するように設計されているため、トランクへのすべてのコミットで実行されます。この頻度のために時間の制約があります。コミットフェーズは一般的に五分以内に完了すべきであり、十分以上かかるべきではありません。多くのセキュリティツールはそれほど迅速には実行できないため、セキュリティに対してこの制約に従うことは非常に困難です (#paul, #mcgraw) 。

CI/CD はあるコンテキストでは「継続的インテグレーション/継続的デリバリー」を意味し、別のコンテキストでは「継続的インテグレーション/継続的デプロイメント」を意味します。実際には、ロジックは以下の通りです。

  • 継続的インテグレーション ビルドアクション (コミットによりトリガーされるか、定期的に実行される) はすべてのソースコードを使用して候補リリースをビルドします。それからテストを実行して、セキュリティ、品質などの規則にリリースが準拠していることを確認します。ケースに準拠していることを確認した場合、プロセスを続行します。そうでない場合、開発チームは問題を修正して、変更を提案する必要があります。

  • 継続的デリバリー 候補リリースは実稼働前環境に進みます。それからリリースを妥当性確認 (手動でまたは自動で) できた場合、デプロイメントを続行します。そうでない場合、プロジェクトチームに通知され、適切な措置を講じる必要があります。

  • 継続的デリバリー リリースはインテグレーションから本稼働に直接移行されます。たとえば、ユーザーがアクセスできるようになります。但し、前のアクティビティで重大な欠陥が特定された場合にはリリースを本稼働に移行すべきではありません。

機密性が低いまたは中程度のアプリのデリバリーとデプロイメントは単一のステップにマージされ、デリバリー後に妥当性確認が実行されることがあります。但し、機密性の高いアプリにはこれら二つのアクションを分離して強力な妥当性確認を使用することを強く推奨します。

セキュリティ

この時点での大きな疑問があります。コードのデリバリーに必要な他のアクティビティを十分に高速かつ効果的に完了した今、セキュリティはどのように維持できますか？適切なレベルのセキュリティをどのように確保できますか？セキュリティを低下させて、より頻繁にユーザーに価値をデリバリーすることは明らかに良くありません！

繰り返しますが、答えは自動化とツール化です。プロジェクトライフサイクル全体でこれら二つのコンセプトを実装することにより、セキュリティを維持し改善できます。セキュリティの期待レベルが高いほど、より多くのコントロール、チェックポイント、および主張が行われます。以下に例を示します。

  • 静的アプリケーションセキュリティテストを開発フェーズで実施し、スキャン結果に多かれ少なかれ重点を置いて継続的インテグレーションプロセスに統合します。多かれ少なかれ要求の厳しいセキュアコーディングルールを確立し、SAST ツールを使用して実装の有効性を確認します。

  • 動的アプリケーションセキュリティテストはアプリがビルドされた後 (継続的インテグレーションが行われた後など) およびデリバリー前に、結果に多かれ少なかれ重点を置いて自動的に実行されます。

  • デリバリーとデプロイメント間など、連続したフェーズ間で手動の妥当性確認チェックポイントを追加します。

DevOps で開発されたアプリのセキュリティは運用の中で考慮する必要があります。以下に例を示します。

  • スキャンは定期的に実行すべきです (インフラストラクチャレベルとアプリケーションレベルの両方で) 。

  • ペンテストは定期的に行います。 (本稼働で使用されるバージョンのアプリはペンテストすべきバージョンであり、テストは専用の環境で本稼働バージョンデータと同様のデータを含めて行うべきです。詳細についてはペネトレーションテストのセクションを参照してください。)

  • アクティブモニタリングを実行すべきです。フィードバックループを介してできるだけ早く問題を特定し修正すべきです。

参考情報

  • [paul] - M. Paul. Official (ISC)2 Guide to the CSSLP CBK, Second Edition ((ISC)2 Press), 2014

  • [mcgraw] - G McGraw. Software Security: Building Security In, 2006

Previousモバイルアプリケーションの分類Nextモバイルアプリの認証アーキテクチャ

Last updated