仕事の関係でここにミディアムで記事を書くのは久しぶりです。

今、戻ってきました!! そして今回は、連載の第 2 部「DevSecOps の全体像」です。

前回の記事では、DevSecOps の世界、その段階、そして哲学について一緒に発見しました。

https://medium.com/@ayoubnajim/devsecops-the-big-picture-part-1-5ca3278c03f

今回は、DevSecOps の最初の段階である計画について説明します。脅威モデリング。

目次 :

1. 計画段階とは何ですか?
2. 脅威モデリングとは何ですか?
3. ユースケース: 電子商取引アプリの脅威モデリング

DevOps ライフサイクルでは、「計画」は最初の段階であり、ソフトウェア開発プロジェクトの初期計画と準備が含まれます。この段階では、プロジェクトの目標を定義し、要件と制約を特定し、プロジェクトの範囲を決定することに重点を置きます。

計画段階で、チームはプロジェクトの概要を確立し、主要な関係者、その要件、役割と責任を特定します。チームは、アプリケーションの開発、テスト、展開、監視に使用するテクノロジーとツールも特定します。

計画段階のもう 1 つの重要な側面は、プロジェクトのタイムライン、マイルストーン、成果物の概要を示すロードマップまたはプロジェクト計画の作成です。この計画は、プロジェクトの範囲、スケジュール、予算を明確に理解し、進捗状況を追跡し、必要に応じて調整を行うための基礎として機能します。

脅威モデリングとは何ですか?

脅威モデリングは、システムまたはアプリケーションの潜在的な脅威と脆弱性を特定し、優先順位を付けるための構造化されたアプローチです。これは、潜在的な脅威を体系的に特定して分析し、それらの脅威の可能性を考慮し、システムまたはアプリケーションに与える可能性のある潜在的な影響に基づいて優先順位を付けることを含む予防的なプロセスです。

脅威モデリングの目標は、攻撃者によって悪用される前にセキュリティの脆弱性を特定して対処することです。潜在的な脅威と脆弱性を体系的かつ体系的に分析することで、組織は直面するセキュリティ リスクをより深く理解し、適切なリスク軽減戦略を開発できます。

通常、脅威のモデリングには、資産と潜在的な脅威の特定、潜在的な脆弱性の分析、可能性と影響に基づいたリスクの優先順位付け、軽減戦略の開発と実装など、いくつかの手順が含まれます。このプロセスは、システムやアプリケーションの開発や保守に関与するセキュリティ専門家、開発者、またはその他の関係者によって実行される場合があります。

ユースケース: 電子商取引アプリの脅威モデリング

e コマース アプリの詳細な脅威モデリングと例を次に示します。

資産を特定する:

最初のステップは、e コマース アプリの資産を特定することです。資産には、顧客の個人データ、支払いデータ、会社情報、IT リソースが含まれる場合があります。

例: 顧客の個人データには、名前、住所、電子メール アドレス、クレジット カード情報が含まれます。

脅威を特定する:

次に、e コマース アプリのセキュリティを侵害する可能性のある潜在的な脅威を特定する必要があります。e コマース アプリに対する一般的な脅威には次のようなものがあります。

• マルウェア攻撃: マルウェア攻撃は、e コマース アプリの Web サイトまたは顧客のデバイスに感染し、攻撃者がデータを盗んだり、他の攻撃を仕掛けたりする可能性があります。
• SQL インジェクション攻撃: SQL インジェクション攻撃により、攻撃者は e コマース アプリのデータベース内の機密データにアクセスしたり、そのデータを変更したりできる可能性があります。
• クロスサイト スクリプティング (XSS) 攻撃: XSS 攻撃により、攻撃者は e コマース アプリの Web サイトに悪意のあるコードを挿入し、データを盗んだり、他の攻撃を開始したりすることができます。
• 分散型サービス拒否 (DDoS) 攻撃: DDoS 攻撃により、e コマース アプリのサーバーに過負荷がかかり、顧客がアプリを利用できなくなる可能性があります。
• 中間者 (MITM) 攻撃: MITM 攻撃により、攻撃者は顧客と e コマース アプリの間で送信されるデータを傍受し、変更することができます。
• アカウントの乗っ取り: アカウントの乗っ取りにより、攻撃者が顧客のアカウントにアクセスし、個人データや支払いデータが盗まれる可能性があります。
• ソーシャル エンジニアリング攻撃: ソーシャル エンジニアリング攻撃は、顧客や従業員をだましてログイン資格情報や支払いデータなどの機密情報を漏らす可能性があります。

脆弱性を分析します。

潜在的な脅威を特定したら、次のステップは、攻撃者がこれらの攻撃を開始するために悪用する可能性のある脆弱性を分析することです。e コマース アプリの一般的な脆弱性には次のようなものがあります。

• 弱いパスワード: 弱いパスワードを使用すると、攻撃者がログイン資格情報を推測し、機密データにアクセスすることが容易になります。
• 安全でない API: 安全でない API を使用すると、攻撃者が e コマース アプリのデータベース内のデータにアクセスしたり、データを変更したりする可能性があります。
• 暗号化されていないデータ送信: 暗号化されていないデータ送信により、攻撃者が顧客と e コマース アプリの間で送信されたデータを傍受して読み取ることができる可能性があります。
• 入力検証の欠如: 入力検証の欠如により、攻撃者が e コマース アプリの Web サイトまたはデータベースに悪意のあるコードを挿入できる可能性があります。
• 古いソフトウェアとフレームワーク: 古いソフトウェアとフレームワークには、攻撃者が悪用できる既知の脆弱性が含まれている可能性があります。
• アクセス制御の欠如: アクセス制御の欠如により、権限のないユーザーが機密データにアクセスできる可能性があります。
• 不適切なロギングとモニタリング: 不適切なロギングとモニタリングにより、攻撃の検出と対応が困難になる可能性があります。

脅威に優先順位を付ける:

脆弱性を特定したら、次のステップは、e コマース アプリに与える可能性のある影響の重大度に基づいて脅威に優先順位を付けることです。たとえば、データベース全体を侵害する SQL インジェクション攻撃は、一時的な中断のみを引き起こす DDoS 攻撃よりも重大な影響を与える可能性があります。

例: クレジット カード情報を盗む SQL インジェクション攻撃は、経済的損失を引き起こし、e コマース アプリの評判を損なう可能性があるため、優先度が高くなります。

脅威を軽減します:

最後に、e コマース アプリ開発チームは、脅威に優先順位を付けた後、これらの脅威を軽減するための措置を講じる必要があります。一般的な緩和戦略には次のようなものがあります。

• 強力なアクセス制御の実装: アクセス制御により、e コマース アプリ内の機密データや機能にアクセスできるユーザーを制限できます。これには、役割ベースのアクセス制御の実装、強力なパスワードの要求、多要素認証の使用などが含まれます。
• 暗号化の実装: 暗号化は、転送中および保存中の機密データの保護に役立ちます。たとえば、SSL/TLS 暗号化を実装すると、顧客と e コマース アプリ間のデータ送信を安全に行うことができ、e コマース アプリのデータベースに保存されている機密データを暗号化することで、不正アクセスを防ぐことができます。
• ソフトウェアとフレームワークを定期的に更新する: 定期的に更新することで、既知の脆弱性に対処し、攻撃のリスクを軽減できます。これには、e コマース アプリのソフトウェア、Web サーバー、オペレーティング システム、およびアプリで使用されるサードパーティのライブラリやフレームワークの更新が含まれます。
• 定期的なセキュリティ監査と脆弱性評価の実施: 定期的なセキュリティ監査と脆弱性評価は、対処する必要がある潜在的な脆弱性や脅威を特定するのに役立ちます。これには、侵入テスト、コードレビュー、脆弱性スキャンの実施が含まれます。
• ロギングとモニタリングの実装: ロギングとモニタリングを実装すると、潜在的な攻撃を検出して対応するのに役立ちます。これには、侵入検知および防御システムの実装、異常なアクティビティに対するアラートの設定、潜在的なセキュリティ インシデントのログの定期的なレビューが含まれます。
• 従業員と顧客にセキュリティ トレーニングを提供する: 従業員と顧客にセキュリティのベスト プラクティスを教育することは、ソーシャル エンジニアリング攻撃のリスクを軽減し、全体的なセキュリティ意識を向上させるのに役立ちます。

次まで!!