ソフトウェア・インテグリティ

 

セキュアなソフトウェア開発ライフサイクルの工程

 

シノプシスのソフトウェア・インティグリティ・ツールベルト

多くの組織はソフトウェアの開発時に一般的な開発プロセスに従っていますが、一般的なプロセスでは通常セキュリティの欠陥を検証(テスト)フェーズで特定するため、開発プロセスではセキュアなソフトウェアの構築にほとんど対応していません。ソフトウェア開発ライフサイクル(SDLC)の後工程での欠陥の修正は、多くの場合、高コストになります。したがって、計画フェーズからリリースまでのSDLCの全工程にセキュリティを組み込むことが推奨されます。これにより、発生後すぐに欠陥を発見(および修正)することが可能になります。

以下では、SDLCのさまざまなフェーズと各工程で導入する一般的なセキュリティ・アクティビティをご紹介します。

強固な計画から始める

計画段階では、アナリストがステークホルダーと緊密に協働してアプリケーションの機能特性と非機能特性(パフォーマンスなど)を定めます。たとえば、顧客がモバイル・バンキング・アプリケーションを利用する場合には電信送金の機能が必要です。

この段階でのセキュリティ・アクティビティからセキュリティ要件が導き出されます。まず、機能セキュリティ要件と非機能セキュリティ要件との違いを明確にしておきましょう。

  • 機能セキュリティ要件定義では、アプリケーションに搭載する必要があるセキュリティ機能(振る舞い)を文書化します。例:「ログインの試行を5回失敗したユーザーはロックアウトする」
  • 非機能セキュリティ要件は、アプリケーションの状態を定義します。例:「サーバー監査ログはフォレンジックに対応するために十分な詳細情報を記録し、サーバーのタイムスタンプ、実行されたアクション、アクションを起動したユーザーのID、操作が行われる前後のシステム状態などを含んでいる必要がある」

アナリストは次の4種類のソースからセキュリティ要件を導き出します。

  • 法律と規制
  • 営業上の考慮事項
  • 契約上の義務
  • アプリケーション自体

法律と規制は個人情報の取り扱いを規定します。ペイメント・プロセッサーとの契約は財務データの保存方法を規定します。

アプリケーション自体からもさまざまな要件が発生します。アナリストはアプリケーションの機能がどの程度悪用可能であるかを評価し、該当箇所を悪用ケース(セキュリティのユースケースに相当)として文書化します。例として、顧客がファイル・アップロード機能を利用してマルウェアをアップロードする場合などが挙げられます。

これは重要なポイントにつながります。効果的なセキュリティ要件定義書の作成は簡単ではありません。

セキュリティ要件は次のとおりです。

  1. テスト可能であること
  2. あいまいでないこと
  3. 測定可能であること
  4. 網羅的であること
  5. 一貫性があること

設計

設計工程では、アーキテクトは承認された要件を満たす概要設計を選択し、アプリケーションをさまざまなコンポーネントに細分化し、テクノロジー・スタックを規定します。たとえば、「Javaで開発されたRESTバックエンドと通信するモバイル・アプリをクラウドでデプロイする」のように定義することができます。

長年の経験からわかったことですが、セキュリティの問題をもたらすソフトウェアの不具合の半分(そうです、半分です)はこの段階で生じます。この段階でのセキュリティ・アクティビティは、設計をレビューしてこうしたセキュリティの欠陥を発見することです。このような脆弱性の例として、REST APIとの通信にTLSなどのセキュア・チャネルを利用していないモバイル・バンキング・アプリケーションが挙げられます。厳格さのレベルに応じて、設計レビューを実行するアクティビティは異なります。

  • Security Control Design Analysis(SCDA)は、セキュリティ・コントロールが業界のベストプラクティスに準拠しているか、違反しているかを判断します。たとえば、ソルトを付加したハッシュ化形式(例: 45918C9ABC755E3958DE66CC7B0EE446276CEAE9836CB457C8C71FB28F970F26)を用いず、プレーンテキスト形式(例:Password01)で保存されているパスワードを検出することができます。
  • 脅威モデリングは、各種の脅威エージェントのアタックサーフェスへのアクセス方法を示すことによって脆弱性の発見を支援します。たとえば、内部のバックエンドでアクセス制御のチェックを行っていない銀行で、悪意のあるインサイダーによる財務情報へのアクセスが可能になっていることを検出できます。
  • アーキテクチャ・リスク解析は、脅威モデリングに依存関係解析と既知の攻撃の解析を加え、攻撃を成功させる可能性がある欠陥を探します。たとえば、バンキング・テスト・システムのテスト入力に本番データが使用されていることを検出できます。アーキテクチャ・リスク解析では、技術的リスクを重大度に応じて格付けします。

実装

実装工程では、開発チームが既定の仕様に従ってアプリケーションを完成させます。この工程のセキュリティ・アクティビティはテクノロジー固有のセキュア・コーディング・ガイドライン(自動)コード・レビューが中心になります。

一般に、テクノロジー固有のガイダンスは開発チームがシステムをセキュアに実装するためのチェックリストの形式をとります。チェックリストには避けるべき事項とセキュアな代替手段を含めることもできます。ガイドラインは実践的(セキュアな実装方法を示している)であり言語またはフレームワーク(Node.jsなど)固有であることが必要です。たとえば、PHPの開発では、データの暗号化に(廃止されるmcryptの暗号化関数ではなく)libsodiumのcrypto_aead_aes256gcm_encrypt関数を使用することが推奨されます。

コード・レビューでは、開発者がこのようなセキュリティ上のミスを犯しているかどうかを確認します。こうしたコード・レビューを自動化するツールは静的アプリケーション・セキュリティ・テスト(SAST)ツールと呼ばれます。SASTツールはニーズに応じた包括的予防的なソリューションを実現します。また、標準的な開発環境(Eclipseなど)にSASTツールを統合して、セキュリティ上のミスが発生した時点ですぐに開発者に通知するようにすることもできます。つまり入力と同時にスペルミスのある単語を検出するスペルチェッカーのような機能を果たします。

SASTツールをCI/CDパイプラインに統合し、開発者が新規に作成した非セキュアなコードを本番コードとマージできないようする(自動セキュリティ・テストに合格しないようにする)こともできます。

検証

SDLCの検証工程では、開発チームまたはテスト・チームがアプリケーションの不具合を確認します。不具合の例として、1より小さい金額を入力するとモバイル・バンキング・アプリの送金ボタンが機能しない場合が挙げられます。

この段階でのセキュリティ・アクティビティでは、アプリケーションの実行時のセキュリティ上の不具合を探します。セキュリティ上の不具合の例として以下が挙げられます。

  • モバイル・バンキング・アプリケーションでマイナス金額の送金(他人の口座から自分の口座への資金移動)が可能になっている
  • モバイル・アプリケーションがユーザーのパスワードをプレーンテキストでSDカードに保存するようになっている
  • Webページのレンダリングがクロスサイト・スクリプティングに対して脆弱になっている

SDLC全体のソフトウェア・テスト・ライフサイクルには以下のテストが含まれます。

  • ペネトレーション・テスト(ペンテスト)。テスト・チームはコンピューター・システム、ネットワーク、(Web)アプリケーションを検査し、攻撃者によるエクスプロイトの可能性がある脆弱性を検出します。たとえば、バンキング・アプリケーションのテスト担当者が、パスワード入力を一定回数失敗したユーザーをアプリケーションがロックアウトするかどうかを確認する場合などがこれに当たります。ロックアウトするようになっていない場合、パスワードの総当たり攻撃に見舞われる可能性があります。テスト担当者は、テストの自動化を支援する動的アプリケーション・セキュリティ・テスト(DAST)ツールを利用することができますが、ツールは誤検知する(エクスプロイト可能でもエクスプロイトできないという結果を出す)ことがあるので、検出結果をテスト担当者が確認する必要があります。
  • ファジングテスト。テスト担当者がアプリケーションに故意に不正な形式の入力を送信することによって脆弱性を検出します。たとえば、テスト担当者がバンキング・サーバーのTLSエンドポイント(HTTPS通信の相手側)に不正な形式のTLSパケットを送信することなどが考えられます。ファジング・ツールは不正な形式の入力を作成する形でこのプロセスを自動化し、その入力をターゲット・ソフトウェアに送信してアプリケーションの障害を検出します。
  • インタラクティブ・アプリケーション・セキュリティ・テスト(IAST)。DASTとランタイム・コンポーネントを組み合わせて誤検知を削減します。ランタイム・コンポーネントはアプリケーションのランタイム(サーバー側のJVMなど)に組み込まれているため、DASTツールで実行した攻撃の結果としてアプリケーションが通過したコードパスを洞察できます。これは誤検知の可能性がある攻撃をIASTツールが拒否するために役立ちます。

テストを効果的かつ効率的に行うため、テスト担当者は各自が異なるアーキテクチャおよびテクノロジー・スタックを専門にしています。モバイル、Web、組み込みアプリケーションシッククライアントIoTはいずれも専門的なスキルセットが必要です。

リリースと対応

リリース工程では、アプリケーションをさまざまな依存関係と共に本番環境にデプロイしてユーザーが使用できるようにします。たとえば、TLS対応のアプリケーションをOpenSSL 1.0.1ライブラリと共にデプロイすることが考えられます。

この工程のセキュリティ・アクティビティでは、アプリケーションの依存関係に既知の脆弱性が存在するかどうかを確認します(そして見つかった脆弱性の阻止またはリスク低減の方法を提示します)。例として、Heartbleedに対して脆弱なOpenSSL 1.0.1を利用しているアプリケーションの検出が挙げられます。こうした(脆弱な)依存関係の検出はソフトウェアコンポジション解析ツールで自動化できます。

アプリケーションのデプロイ後にテスト・チームがレッドチーム評価を行う必要もあります。このアクティビティでは、実際的な敵対行為によるシステムへの攻撃をモデリングします。また、個々には些細に見えてもまとめて攻撃されると重大な損害をもたらす可能性がある脆弱性を攻撃して、システムの耐性を検証します。テストでは、実際の攻撃者のように、アプリケーションの脆弱性だけではなく、アプリケーションをデプロイしている環境(ネットワーク、ファイアウォール、オペレーティング・システムなど)、運用手順、人(ロールベースのソーシャル・エンジニアリングなど)の弱点も考慮します。

セキュリティに関するトレーニング

教育はあらゆる セキュアなソフトウェア開発ライフサイクル(SSDLC) の基礎です。チーム全員が基本的なソフトウェア・セキュリティ教育を受けるようにし、セキュリティの重要性に対する意識とセキュリティ・エンジニアリングの基礎知識の向上を図る必要があります。エンジニア・グループが新しい脅威に関する最新の知識を維持するための高度な教育を受けるようにするのも1つの方法です。

一連のアクティビティのカスタマイズ

この記事でご紹介したセキュリティ・アクティビティはさまざまな企業が実践しているアクティビティのほんの一部にすぎません。自社のソフトウェア・セキュリティ対策(SSI)の定義・構築(または成熟)を支援するソフトウェア・セキュリティ・ロードマップを独自に作成することをお勧めします。

その計画では、ソフトウェア・セキュリティ戦略を定義し、組織の目的に適ったセキュリティ・アクティビティを選択する必要があります。自社の対策が同業他社と比較してどの程度進んでいるかを検証するという方法もあります。SSIによるアプリケーションのセキュリティ体制の向上を測定指標と共に示すことが重要です。

何よりも、セキュリティ・テストをSDLCの早い段階で取り入れるほどセキュリティ上の不具合を修正するためのコストが低減することを覚えておいてください。

御社のニーズに最適なソリューションを探してください。

開始