安全なソフトウェア開発ライフサイクルの進め方

多くの組織はソフトウェアの開発時に一般的な開発プロセスに従っていますが、一般的なプロセスでは通常セキュリティの欠陥を検証（テスト）フェーズで特定するため、開発プロセスではセキュアなソフトウェアの構築にほとんど対応していません。ソフトウェア開発ライフサイクル（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はいずれも専門的なスキルセットが必要です。