SSDLC（安全なソフトウェア開発ライフサイクル）の対策

measures ssdlc

安全なSDLCまたはSSDLCのために実装するさまざまなセキュリティ対策について学習します。

テクノロジーが急速に成長するにつれて、セキュリティで保護されたデータをハッキングしたり盗んだりするというセキュリティ関連の脅威もそれに応じて増加しています。したがって、テクノロジーの成長がソフトウェアメーカーに課題を投げかけ、ソフトウェアがセキュリティの脅威や脆弱性に対して強力で堅牢であることを保証していることは間違いありません。

ソフトウェア製品は、高度に保護され、指定および規制されたセキュリティとプライバシーの基準を満たしていることが証明されない限り、意図した機能に対して完全に機能していても、特に個人データや財務データを含む防衛、財務、ヘルスケアなどの分野でリリースすることはできません。 。

製品の重大度が高または中であっても、展開時に製品にセキュリティ上の欠陥を持たせる余裕はありません。したがって、あらゆる種類の攻撃、悪意のある脅威、脆弱性からソフトウェアとデータを保護し、エンドユーザーに対するソフトウェアの信頼性を確保することが非常に重要です。

従来のソフトウェア開発とは異なり、ソフトウェア全体が開発された後の最後のフェーズでのテストは、もはや効果的ではありません。アジャイル、DevOps、ShiftLeftの概念を実装することで、アプリケーションのライフサイクルの初期段階とすべての段階でテストを実行することが不可欠です。

そうは言っても、ソフトウェアのセキュリティは最終段階で構築したりテストしたりすることはできないため、ソフトウェアの全体的なセキュリティを確保するには、すべてのフェーズで構築する必要があります。

学習内容：

• SSDLCのセキュリティ対策
  • ＃1）要件フェーズ
  • ＃2）計画フェーズ
  • ＃3）アーキテクチャと設計フェーズ
  • ＃4）開発フェーズ
  • ＃5）実装フェーズ
  • ＃6）テスト–展開前フェーズ
• SSDLCの表形式の要約
• 結論
  • 推奨読書

SSDLCのセキュリティ対策

以下に示すのは、セキュアSDLCまたはSSDLCを確保するために、ソフトウェア開発ライフサイクル全体で実装できるセキュリティ関連のさまざまな手段です。可能な限り、欠陥を次のフェーズに進めることはできません。

SDLCフェーズでセキュリティを構築する必要があるさまざまなセキュリティ分析と評価があります。

1. 要件フェーズ
2. 計画段階
3. アーキテクチャと設計フェーズ： 設計に基づくセキュリティリスク評価。
4. 開発フェーズ： セキュアコード分析、セキュリティのためのコードの静的分析。
5. 実装フェーズ： 動的コード分析、アプリケーションセキュリティテスト。
6. テスト–展開前フェーズ： ペネトレーションテストと脆弱性分析。

＃1）要件フェーズ

• 主に、必要なセキュリティ対策がソフトウェアに組み込まれていることを確認するために、 セキュリティ関連の特定の要件 要件フェーズでは、十分な詳細と期待される結果を明確に把握する必要があります。
• 典型的なユースケースとビジネスシナリオを特定しながら、 セキュリティ関連のユースケースとシナリオ 検証の目的で、セキュリティ機能をキャプチャし、セキュリティテストシナリオを設計するために特定する必要があります。

以下に示すのは、キャプチャできる明示的なセキュリティ関連の要件を示すいくつかのサンプル例です。

Sec-Req-01： システムは、すべてのゲートウェイと入口ポイントで認証手段を実施する必要があります。

Sec-Req-02： システムは、安全なログイン画面を介して認証を実装する必要があります。

Sec-Req-03： 個人データは保存時に暗号化されます。

＃2）計画フェーズ

これらに限定されるものではありませんが、大まかに言えば、計画段階では次の点に注意する必要があります。

5年間の経験のためのInformaticaインタビューの質問と回答

• 強い、 専用セキュリティチーム 、プログラムチームのPMO（プロジェクト管理オフィス）の外部で機能し、 セキュリティオフィサー、セキュリティアーキテクト、セキュリティテスター プログラムのすべてのセキュリティ関連の活動を公平な方法で実行および管理するために形成されます。これらの役割ごとに、明確なRnR（役割と責任）とRACIが定義されています。
• どれか エスカレーション、あいまいさ セキュリティの問題に関連するものは、セキュリティチームが円滑に機能し、正しい意思決定を支援できるように、PSO（製品セキュリティ責任者）が処理する必要があります。
• 堅牢 セキュリティテスト戦略 セキュリティ関連の要件を実装する方法、テストする方法、時期、内容、各段階で使用するツールを指定する必要があります。
• 関与することが必須です セキュリティの連絡先 プログラムに関連するすべての技術/レビューの議論のために、セキュリティチームがプログラムに起こっている変更を認識できるようにします。

＃3）アーキテクチャと設計フェーズ

設計段階の早い段階でセキュリティの側面にもっと注意を払うことは、セキュリティリスクを防ぎ、SDLCの後の設計変更におけるかなりの労力を減らすのに役立ちます。

ソフトウェア、およびソフトウェアがホストされるインフラストラクチャを設計している間、すべての可能性があります セキュリティ設計の実装 セキュリティアーキテクトの関与を得て適切に設計する必要があります。

機能的側面と非機能的設計およびアーキテクチャの側面の間のあいまいさや矛盾は、適切な利害関係者が関与するブレーンストーミングセッションを通じて整理する必要があります。

このフェーズでは、詳細な製品セキュリティリスク評価も行われます。 「静的評価」 専門家のセキュリティチームが実行する必要があります。

セキュリティリスク評価 予備設計/アーキテクチャ段階でのセキュリティの観点からのプログラムのレビューが含まれ、設計の観点からセキュリティ関連の欠陥を特定し、それに応じて製品を引き上げます。 セキュリティリスク それらに対処し、次のフェーズに入らないようにプロジェクトチームに依頼します。

これらの評価は、これらのドキュメントで概説されている組織/産業のセキュリティガイドライン、標準、および管理に基づいて実行されます。 例えば。 UXW 00320、UXW 030017

製品セキュリティリスク評価中：

• 要件、機能、ユーザーストーリー、およびそれらの設計ドキュメントは、プロジェクトチームによって共有された詳細、成果物に基づいてレビューされます。 例えば。 設計ドキュメント（HLDDおよびLLDD）。評価には、文書がない場合、または疑問があるかどうかを明確にするために、関連するプロジェクトチームメンバーとの話し合いも含まれます。
• プログラムのセキュリティ要件を設定された標準やその他のベストプラクティスに照らしてマッピングする際に、ギャップが特定されます。特定されたギャップに基づいて脅威モデルが開発されることもあります。
• これらのギャップは、潜在的なセキュリティリスクとして識別され、実装の可能な緩和策の提案も含まれ、提起され、管理されます。
• これらの緩和策がプロジェクトチームによって実装されると、システムテストチームによって設計された適切なテストケースを介して、それらが閉鎖されているかどうかが検証されます。
• トレーサビリティを提供するリスク管理マトリックスは、これらのリスクを追跡するために用意されています。残りのリスクを伴う承認と承認は、セキュリティアーキテクトとPSOが行います。

設計段階で特定される典型的な脅威パターンは、入力検証、監査/ログ管理、構成、および暗号化に関連しています。 リスクの特定には、弱いパスワード、単純なブルートフォース攻撃などの攻撃の脆弱性が含まれます。

一般的なレビューには、個人データへのアクセス、監査証跡へのアクセス、エンティティのブラックリストへのホワイトリストへのアクセス、データのクリーニング、および削除アクティビティに関連するリスクが含まれます。

最高のゲーム会社は何ですか

サンプルテストシナリオは次のとおりです。

• バッファオーバーフローの脆弱性： パラメータを手動でファジングすることにより、サーバーの速度を低下させ、サーバーを強制的に応答させないようにする必要があります（サービス拒否）。
• データのサニタイズ： 攻撃者が悪意のあるコンテンツをシステムに挿入して保存できないように、すべての入力と出力に対して適切なデータサニタイズが行われるようにするため。

＃4）開発フェーズ

安全なコード分析 は 静的コード評価 評価に使用される方法 安全なコード 自動スキャンツールを使用したソフトウェアのさまざまな機能の分析。 例： 要塞化。

この分析は、セキュリティの脅威について生成されたコードをスキャンするために、すべてのコードチェックイン/ビルドで実行されます。この評価は通常、ユーザーストーリーレベルで行われます。

• プラグインを介したFortifyスキャンは、開発者のマシンにインストールする必要があります。
• Fortifyはビルドテンプレートと統合する必要があります。
• 自動スキャンは、すべてのビルドで毎日実行されます。
• スキャン結果は、セキュリティチームによって誤検知がないか分析されます。
• この評価によって特定された欠陥は、次のレベルに浸透が最小化/ゼロ化されるように、発生して閉鎖まで管理されます。

サンプルテストシナリオは次のとおりです。

• データ送信中に機密データがプレーンテキストで送信されないようにするため。
• 安全なデータ転送を保証するには、外部向けAPIをHTTPSチャネルにデプロイする必要があります。

＃5）実装フェーズ

動的コード分析 これは、OWASP（Open Web Application Security Project）テストとも呼ばれるアプリケーションセキュリティテストに他なりません。脆弱性分析および侵入テスト（VAPT）は、実装/テストフェーズで実行する必要があります。

この分析では、バイナリといくつかの環境構成を評価し、セキュリティ要件のコードをさらに強化します。

この分析の一環として、 動的な動作 または、プログラムのさまざまな機能の機能が、セキュリティ関連の脆弱性について分析されます。動的コード分析を実行するために、規定されたユースケースとビジネスシナリオも使用されます。

このアクティビティは、 テストビルド 自動化された手動のアプローチでさまざまなセキュリティツールを使用します。

• HP WebInspect、Burp Suite、ZAP、およびSOAP UIツールは、通常、標準の脆弱性データベースに対して脆弱性をチェックするために使用されます（ 例： OWASPトップ10 ）
• ただし、このアクティビティは主に自動化されていますが、特定のツールの制限により、誤検知を優先順位付けするために手動での作業が必要になる場合があります。
• これは、テストの準備ができたソフトウェアが展開されている別の環境（システムテスト環境）で実行するのが理想的です。
• 提案された緩和策を使用して、脆弱性を提起し、閉鎖する必要があります。

この分析中に特定された典型的な脅威パターンは、入力検証、認証とセッション管理の失敗、機密データの公開、XSS、およびパスワード管理に関連しています。

サンプルテストシナリオには、次のものが含まれます。

• パスワード管理： パスワードが構成ファイルまたはシステム内のどこにもプレーンテキストで保存されないようにするため。
• システム情報の漏えい： システム情報がどの時点でも漏洩しないようにするために、printStackTraceによって明らかにされた情報は、攻撃の計画から攻撃者を助けることができます。

＃6）テスト–展開前フェーズ

ペネトレーションテスト 、要するにペンテストと インフラVAPT（脆弱性分析および侵入テスト） は、本格的なホリスティックテストです。 完全なソリューション そして 構成 （ネットワークを含む）これは、製品前または本番環境のような環境で理想的に実行されます。

これは主に、DBの脆弱性とサーバーの脆弱性を他の脆弱性とともに特定するために実行されます。これは、実施されるセキュリティテストの最終段階です。したがって、これには、以前に報告された欠陥とリスクの検証も含まれます。

• 市場で入手可能なNessus、Nmap、HP Web Inspect、Burp Suite、ZAPなどのツールを使用して、侵入テストを実行します。
• このテストでは、自動化されたツールを使用したWebアプリケーションのスキャンと、さらなる検証のための活用が行われます。テストは実際の攻撃者の行動をシミュレートするために行われるため、いくつかの否定的なテストも含まれる場合があります。
• インフラストラクチャの脆弱性 評価には、インフラストラクチャ（ネットワーク、システム、およびサーバー）のスキャン、分析、およびセキュリティ構成のレビューが含まれ、脆弱性を特定し、標的となる攻撃に対する回復力をチェックします。
• これは、実稼働前または実稼働のような環境で実行されます。この環境では、展開の準備ができているソフトウェアがテストされ、リアルタイム環境がシミュレートされます。
• 脆弱性は、スキャナーと手動技術の両方を使用して識別され、誤検知を排除します。また、手動テスト中にリアルタイムのビジネスシナリオが実行されます。
• プログラム全体に対して実行されるセキュリティ分析全体に関する最終レポートが作成され、リスクの高い項目がある場合はそのステータスが強調表示されます。

サンプルテストシナリオには、次のものが含まれます。

• 脆弱なHTTPメソッドが有効になっていないことを確認します。
• 他のユーザーの機密情報がネットワーク上でクリアテキストで表示されないようにするため。
• 悪意のあるファイルのアップロードを回避するために、ファイルアップロードの検証が実装されていることを確認します。

SSDLCの表形式の要約

以下の表は、上記で説明したセキュリティ分析のさまざまな側面をまとめたものです。

結論

したがって、SDLCのさまざまなフェーズにわたって統合されたこれらすべてのセキュリティ関連の側面の実装により、組織はサイクルの早い段階でセキュリティの欠陥を特定し、組織が適切な緩和策を実装できるようになり、それによって 高リスクのセキュリティ上の欠陥 ライブシステムで。

この調査では、セキュリティ上の欠陥の大部分が開発段階、つまり コーディングフェーズ 、ここで、コーディングは、何らかの理由により、すべてのセキュリティ面を十分に処理していません。

理想的には、セキュリティを危険にさらすような悪いコードを書きたくない開発者はいないでしょう。したがって、セキュアソフトウェアの作成方法について開発者をガイドするために、次のチュートリアルでは ベストプラクティスとコーディングガイドライン 開発者向け、ソフトウェアのセキュリティを強化します。

SecureSDLCまたはSSDLCに関するこのチュートリアルがお役に立てば幸いです。

推奨読書

• SDLC（ソフトウェア開発ライフサイクル）のフェーズ、方法論、プロセス、およびモデル
• 2021年の10の最高のモバイルAPPセキュリティテストツール
• 192021年にプロが使用した強力な侵入テストツール
• モバイルアプリのセキュリティテストガイドライン
• ネットワークセキュリティテストと最高のネットワークセキュリティツール
• セキュリティテスト（完全ガイド）
• Webアプリケーションをテストするためのトップ4のオープンソースセキュリティテストツール
• Webアプリケーションセキュリティテストガイド