銀行の現金以外の支払いの情報セキュリティ。 パート 8 - 典型的な脅威モデル

研究は何についてですか?

研究の他の部分へのリンク

• 銀行の現金以外の支払いの情報セキュリティ。 パート 1 - 経済の基礎。
• 銀行の現金以外の支払いの情報セキュリティ。 パート 2 - 典型的な銀行の IT インフラストラクチャ。
• 銀行の現金以外の支払いの情報セキュリティ。 パート 3 - 保護システムの要件の形成。
• 銀行の現金以外の支払いの情報セキュリティ。 パート 4 - 脅威モデリング標準のレビュー。
• 銀行の現金以外の支払いの情報セキュリティ。 パート 5 - 銀行ハッキングに関する 100 以上のテーマ別リンク。
• 銀行の現金以外の支払いの情報セキュリティ。 パート 6 - 銀行犯罪の分析。
• 銀行の現金以外の支払いの情報セキュリティ。 パート 7 - 基本的な脅威モデル。
• 銀行の現金以外の支払いの情報セキュリティ。 パート 8 - 典型的な脅威モデル (あなたはここにいますか)

この記事は、銀行の現金以外の支払いの情報セキュリティの確保に特化した一連の出版物を完成させます。 ここでは、で言及されている典型的な脅威モデルを見ていきます。 ベースモデル:

• 典型的な脅威モデル。 ネットワーク接続.
• 典型的な脅威モデル。 クライアントサーバー型のアーキテクチャで構築された情報システム.
• 典型的な脅威モデル。 アクセス制御システム.
• 典型的な脅威モデル。 統合モジュール.
• 典型的な脅威モデル。 暗号化情報保護システム。

ハブロ警告!!! 親愛なるハブロビ人の皆さん、これは面白い投稿ではありません。
カットの下に隠された 40 ページ以上の資料の目的は、 仕事や勉強を手伝う 銀行業務や情報セキュリティを専門とする人々。 これらの資料は研究の最終成果物であり、ドライで形式的な口調で書かれています。 本質的に、これらは内部情報セキュリティ文書用の空白です。

まあ、伝統的な - 「記事の情報を違法な目的で使用すると法律で罰せられます。」。 生産的な読書！

この出版物から研究に精通する読者向けの情報。

研究は何についてですか?

あなたは、銀行における支払いの情報セキュリティの確保を担当する専門家向けのガイドを読んでいます。

プレゼンテーション ロジック

初めに 1の一部 и 2の一部 保護されたオブジェクトの説明が与えられます。 それから 3の一部 セキュリティ システムを構築する方法を説明し、脅威モデルを作成する必要性について説明します。 で 4の一部 どのような脅威モデルが存在し、どのように形成されるのかについて説明します。 で 5の一部 и 6の一部 実際の攻撃の分析が提供されます。 Часть7 и パート8 これまでのすべてのパートからの情報を考慮して構築された脅威モデルの説明が含まれています。

典型的な脅威モデル。 ネットワーク接続

脅威モデル（スコープ）が適用される保護オブジェクト

保護の対象となるのは、TCP/IP スタックに基づいて構築されたデータ ネットワークで動作するネットワーク接続を介して送信されるデータです。

アーキテクチャ

建築要素の説明:

• 「エンドノード」 — 保護された情報を交換するノード。
• 「中間ノード」 — データ伝送ネットワークの要素: ルーター、スイッチ、アクセス サーバー、プロキシ サーバー、その他の機器 — ネットワーク接続トラフィックの伝送に使用されます。 一般に、ネットワーク接続は中間ノードなしで (エンド ノード間で直接) 機能します。

トップレベルのセキュリティ脅威

分解

U1。 送信データへの不正アクセス。
U2。 送信データの不正な改ざん。
U3。 送信されたデータの著作権の侵害。

U1。 送信データへの不正アクセス

分解
U1.1。 <…>、最終ノードまたは中間ノードで実行されます。
U1.1.1。 <…> ホスト ストレージ デバイスにあるデータを読み取ることにより、次のようになります。
U1.1.1.1。 <…> RAM 内。
U1.1.1.1の説明。
たとえば、ホストのネットワーク スタックによるデータ処理中などです。

U1.1.1.2。 <…> 不揮発性メモリ内。
U1.1.1.2の説明。
たとえば、送信されたデータをキャッシュ、一時ファイル、またはスワップ ファイルに保存する場合です。

U1.2。 <…>、データ ネットワークのサードパーティ ノードで実行されます。
U1.2.1。 <…> ホストのネットワーク インターフェイスに到着するすべてのパケットをキャプチャする方法:
U1.2.1の説明。
すべてのパケットのキャプチャは、ネットワーク カードを無差別モード (有線アダプターの場合は無差別モード、Wi-Fi アダプターの場合はモニター モード) に切り替えることによって実行されます。

U1.2.2。 <…> 中間者 (MiTM) 攻撃を実行しますが、送信データは変更されません (ネットワーク プロトコル サービス データはカウントされません)。
U1.2.2.1。 リンク： 「典型的な脅威モデル。 ネットワーク接続。 U2。 送信データの不正な改ざん」.

U1.3。 <…>、物理ノードや通信回線からのテクニカルチャネル（TKUI）を介した情報漏洩により発生します。

U1.4。 <…> は、情報の秘密収集を目的とした特別な技術手段 (STS) をエンドノードまたは中間ノードにインストールすることによって実行されます。

U2。 送信データの不正な改ざん

分解
U2.1。 <…>、最終ノードまたは中間ノードで実行されます。
U2.1.1。 <…> ノードのストレージ デバイス内にあるデータを読み取り、変更します。
U2.1.1.1。 <…> RAM 内:
U2.1.1.2。 <…> 不揮発性メモリ内:

U2.2。 <…>、データ伝送ネットワークのサードパーティノードで実行されます。
U2.2.1。 <…> 中間者 (MiTM) 攻撃を実行し、トラフィックを攻撃者のノードにリダイレクトします。
U2.2.1.1。 攻撃者の機器が物理的に接続されると、ネットワーク接続が切断されます。
U2.2.1.2。 ネットワーク プロトコルに対する攻撃の実行:
U2.2.1.2.1。 <…> 仮想ローカル ネットワーク (VLAN) の管理:
U2.2.1.2.1.1。 VLANホッピング.
U2.2.1.2.1.2。 スイッチまたはルーターの VLAN 設定を不正に変更する。
U2.2.1.2.2。 <…> トラフィックルーティング:
U2.2.1.2.2.1。 ルーターの静的ルーティング テーブルの不正な変更。
U2.2.1.2.2.2。 動的ルーティング プロトコルを介した攻撃者による偽のルートのアナウンス。
U2.2.1.2.3。 <…> 自動構成:
U2.2.1.2.3.1。 不正な DHCP.
U2.2.1.2.3.2。 不正な WPAD.
U2.2.1.2.4。 <…> アドレス指定と名前解決:
U2.2.1.2.4.1。 ARPスプーフィング.
U2.2.1.2.4.2。 DNSスプーフィング.
U2.2.1.2.4.3。 ローカルホスト名ファイル (hosts、lmhosts など) に不正な変更を加える

U3。 送信データの著作権侵害

分解
U3.1。 データの作成者またはソースに関する虚偽の情報を示すことにより、情報の作成者を決定するメカニズムの無力化:
U3.1.1。 送信情報に含まれる著作者に関する情報を変更すること。
U3.1.1.1。 送信データの完全性と作成者の暗号化保護の無効化:
U3.1.1.1.1。 リンク： 「典型的な脅威モデル。 暗号化情報保護システム。
U4。 虚偽のデータに基づく正当な署名者の電子署名の作成」.
U3.1.1.2。 ワンタイム確認コードを使用して実装された、送信データの著作権保護の無効化:
U3.1.1.2.1。 SIMスワップ.

U3.1.2。 送信された情報のソースに関する情報の変更:
U3.1.2.1。 IPスプーフィング.
U3.1.2.2。 MACスプーフィング.

典型的な脅威モデル。 クライアントサーバーアーキテクチャをベースに構築された情報システム

脅威モデル（スコープ）が適用される保護オブジェクト

保護の対象となるのは、クライアント・サーバー型アーキテクチャに基づいて構築された情報システムです。

アーキテクチャ


建築要素の説明:

• "クライアント" – 情報システムのクライアント部分が動作するデバイス。
• "サーバ" – 情報システムのサーバー部分が動作するデバイス。
• 「データストア」 — 情報システムのサーバー インフラストラクチャの一部であり、情報システムによって処理されたデータを保存するように設計されています。
• "ネットワーク接続" — データネットワークを経由するクライアントとサーバー間の情報交換チャネル。 要素モデルのより詳細な説明は、次のとおりです。 「典型的な脅威モデル。 ネットワーク接続".

制限
オブジェクトをモデリングするときは、次の制限が設定されます。

1. ユーザーは、ワークセッションと呼ばれる限られた時間内で情報システムと対話します。
2. 各作業セッションの開始時に、ユーザーが識別、認証、および許可されます。
3. 保護された情報はすべて、情報システムのサーバー部分に保存されます。

トップレベルのセキュリティ脅威

分解
U1。 正規のユーザーに代わって攻撃者による不正なアクションを実行する。
U2。 情報システムのサーバー部分による処理中に、保護された情報が不正に変更されること。

U1。 正規のユーザーに代わって攻撃者による不正なアクションを実行する

説明
通常、情報システムでは、アクションは以下を使用してそれを実行したユーザーと関連付けられます。

1. システム操作ログ（ログ）。
2. データ オブジェクトの特別な属性。データ オブジェクトを作成または変更したユーザーに関する情報が含まれます。

作業セッションに関連して、この脅威は次のように分解できます。

1. <…> ユーザーセッション内で実行されます。
2. <…> ユーザーセッション外で実行されます。

ユーザーセッションは次のように開始できます。

1. ユーザー自身による。
2. 犯罪者。

この段階で、この脅威の中間分解は次のようになります。
U1.1。 ユーザーセッション内で不正なアクションが実行されました:
U1.1.1。 <…> 攻撃されたユーザーによってインストールされました。
U1.1.2。 <…> 攻撃者によってインストールされました。
U1.2。 不正なアクションがユーザー セッション外で実行されました。

攻撃者の影響を受ける可能性のある情報インフラストラクチャ オブジェクトの観点から、中間脅威の分解は次のようになります。

アイテム
脅威の分解

U1.1.1。
U1.1.2。
U1.2。

クライアント
U1.1.1.1。
U1.1.2.1。

ネットワーク接続
U1.1.1.2。

Сервер

U1.2.1。

分解
U1.1。 ユーザーセッション内で不正なアクションが実行されました:
U1.1.1。 <…> 攻撃されたユーザーによってインストールされました:
U1.1.1.1。 攻撃者はクライアントから独立して行動しました。
U1.1.1.1.1 攻撃者は、次の標準的な情報システム アクセス ツールを使用しました。
U1.1.1.1.1.1。 攻撃者は、クライアントの物理的な入出力デバイス (キーボード、マウス、モニター、またはモバイル デバイスのタッチ スクリーン) を使用しました。
U1.1.1.1.1.1.1。 攻撃者は、セッションがアクティブで、I/O 機能が利用可能で、ユーザーが存在していない時間帯に操作を行いました。
У1.1.1.1.1.2。 攻撃者は、リモート管理ツール (標準または悪意のあるコードによって提供される) を使用してクライアントを管理しました。
U1.1.1.1.1.2.1。 攻撃者は、セッションがアクティブで、I/O 機能が利用可能で、ユーザーが存在していない時間帯に操作を行いました。
U1.1.1.1.1.2.2。 攻撃者はリモート管理ツールを使用しましたが、その操作は攻撃されたユーザーには見えません。
U1.1.1.2。 攻撃者は、クライアントとサーバーの間のネットワーク接続内のデータを置き換え、正規のユーザーのアクションとして認識されるようにデータを変更しました。
U1.1.1.2.1。 リンク： 「典型的な脅威モデル。 ネットワーク接続。 U2。 送信データの不正な改ざん」.
U1.1.1.3。 攻撃者は、ソーシャル エンジニアリング手法を使用して、ユーザーが指定したアクションの実行を強制しました。

У1.1.2 <…> 攻撃者によってインストールされました:
U1.1.2.1。 攻撃者はクライアント (И):
U1.1.2.1.1。 攻撃者は情報システムのアクセス制御システムを無力化しました。
U1.1.2.1.1.1。 リンク： 「典型的な脅威モデル。 アクセス制御システム。 U1。 正規のユーザーに代わってセッションが不正に確立されました。」.
У1.1.2.1.2。 攻撃者は標準的な情報システム アクセス ツールを使用しました
U1.1.2.2。 攻撃者はデータ ネットワークの他のノードから操作し、そこからサーバーへのネットワーク接続を確立できました (И):
U1.1.2.2.1。 攻撃者は情報システムのアクセス制御システムを無力化しました。
U1.1.2.2.1.1。 リンク： 「典型的な脅威モデル。 アクセス制御システム。 U1。 正規のユーザーに代わってセッションが不正に確立されました。」.
U1.1.2.2.2。 攻撃者は情報システムにアクセスするために非標準的な手段を使用しました。
説明U1.1.2.2.2。
攻撃者は、情報システムの標準クライアントをサードパーティのノードにインストールしたり、クライアントとサーバー間の標準交換プロトコルを実装する非標準ソフトウェアを使用したりする可能性があります。

U1.2 不正なアクションがユーザー セッション外で実行されました。
U1.2.1 攻撃者は、不正なアクションを実行した後、情報システムの操作ログやデータ オブジェクトの特別な属性に不正な変更を加え、実行したアクションが正規のユーザーによって実行されたことを示しました。

U2。 情報システムのサーバー部分による処理中に、保護された情報が不正に変更されること

分解
U2.1。 攻撃者は、正規のユーザーに代わって、標準の情報システム ツールを使用して保護された情報を変更します。
U2.1.1。 リンク： 「典型的な脅威モデル。 クライアントサーバーアーキテクチャに基づいて構築された情報システム。 U1。 正規のユーザーに代わって攻撃者による不正なアクションを実行する」.

U2.2。 攻撃者は、情報システムの通常の動作では提供されていないデータ アクセス メカニズムを使用して、保護された情報を変更します。
U2.2.1。 攻撃者は、保護された情報を含むファイルを変更します。
U2.2.1.1。 <…>、オペレーティング システムが提供するファイル処理メカニズムを使用します。
U2.2.1.2。 <…> 不正に変更されたバックアップ コピーからのファイルの復元を引き起こすことによって。

U2.2.2。 攻撃者はデータベースに保存されている保護された情報を変更します (И):
U2.2.2.1。 攻撃者は DBMS アクセス制御システムを無力化します。
U2.2.2.1.1。 リンク： 「典型的な脅威モデル。 アクセス制御システム。 U1。 正規のユーザーに代わってセッションが不正に確立されました。」.
U2.2.2.2。 攻撃者は、標準の DBMS インターフェイスを使用して情報を変更し、データにアクセスします。

U2.3。 攻撃者は、保護された情報を処理するソフトウェアの動作アルゴリズムを不正に変更することで、保護された情報を改ざんします。
U2.3.1。 ソフトウェアのソースコードは変更される場合があります。
U2.3.1。 ソフトウェアのマシンコードは変更されることがあります。

U2.4。 攻撃者は、情報システム ソフトウェアの脆弱性を悪用して、保護されている情報を改ざんします。

U2.5。 攻撃者は、情報システムのサーバー部分のコンポーネント (データベース サーバーとアプリケーション サーバーなど) 間で保護された情報を転送するときに、保護された情報を変更します。
U2.5.1。 リンク： 「典型的な脅威モデル。 ネットワーク接続。 U2。 送信データの不正な改ざん」.

典型的な脅威モデル。 アクセス制御システム

脅威モデル（スコープ）が適用される保護オブジェクト

この脅威モデルが適用される保護オブジェクトは、脅威モデルの保護オブジェクト「典型的な脅威モデル」に対応します。 クライアントサーバーアーキテクチャに基づいて構築された情報システム。」

この脅威モデルでは、ユーザー アクセス制御システムとは、次の機能を実装する情報システムのコンポーネントを意味します。

1. ユーザーの識別。
2. ユーザ認証。
3. ユーザー権限。
4. ユーザーのアクションをログに記録します。

トップレベルのセキュリティ脅威

分解
U1。 正規のユーザーに代わってセッションを不正に確立すること。
U2。 情報システムにおけるユーザー権限の不正な増加。

U1。 正規のユーザーに代わってセッションが不正に確立される

説明
この脅威の分解は一般に、使用されるユーザー識別および認証システムの種類によって異なります。

このモデルでは、テキスト ログインとパスワードを使用するユーザー識別および認証システムのみが考慮されます。 この場合、ユーザーのログイン情報は攻撃者に知られている公開情報であると想定します。

分解
U1.1。 <…> 認証情報の侵害によるもの:
U1.1.1。 攻撃者は、ユーザーの資格情報を保存しているときにそれを侵害しました。
説明U1.1.1。
たとえば、資格情報をモニターに貼り付けた付箋に書き込むことができます。

U1.1.2。 ユーザーが誤ってまたは悪意を持ってアクセスの詳細を攻撃者に渡しました。
U1.1.2.1。 ユーザーは入力時に資格情報を大声で言いました。
U1.1.2.2。 ユーザーは意図的に自分の資格情報を共有しました。
U1.1.2.2.1。 <…> 職場の同僚へ。
説明U1.1.2.2.1。
たとえば、病気のときに交換できるようにするためです。

U1.1.2.2.2。 <…> 情報インフラストラクチャ オブジェクトの作業を行う雇用主の請負業者に。
U1.1.2.2.3。 <…> 第三者へ。
説明U1.1.2.2.3。
この脅威を実装するための唯一の選択肢ではありませんが、攻撃者によるソーシャル エンジニアリング手法の使用が XNUMX つです。

U1.1.3。 攻撃者はブルート フォース手法を使用して資格情報を選択しました。
U1.1.3.1。 <…> 標準のアクセス メカニズムを使用します。
U1.1.3.2。 <…> 資格情報を保存するために、以前に傍受したコード (パスワード ハッシュなど) を使用します。

U1.1.4。 攻撃者は悪意のあるコードを使用してユーザーの資格情報を傍受しました。

U1.1.5。 攻撃者は、クライアントとサーバー間のネットワーク接続から資格情報を抽出しました。
U1.1.5.1。 リンク： 「典型的な脅威モデル。 ネットワーク接続。 U1。 送信データへの不正アクセス」.

U1.1.6。 攻撃者は、作業監視システムの記録から資格情報を抽出しました。
U1.1.6.1。 <…> ビデオ監視システム (操作中にキーボードのキーストロークが記録された場合)。
U1.1.6.2。 <…> 従業員のコンピュータでの行動を監視するシステム
説明U1.1.6.2。
そのようなシステムの例としては、 スタッフコップ.

U1.1.7。 攻撃者は、送信プロセスの欠陥によりユーザーの資格情報を侵害しました。
説明U1.1.7。
たとえば、パスワードを平文で電子メールで送信します。

U1.1.8。 攻撃者は、リモート管理システムを使用してユーザーのセッションを監視することで資格情報を入手しました。

U1.1.9。 攻撃者は、テクニカル チャネル (TCUI) を介した漏洩の結果として資格情報を取得しました。
U1.1.9.1。 攻撃者は、ユーザーがキーボードから資格情報を入力する様子を観察しました。
U1.1.9.1.1 攻撃者はユーザーのすぐ近くにいて、資格情報の入力を自分の目で見ました。
説明 U1.1.9.1.1
このようなケースには、職場の同僚のアクションや、ユーザーのキーボードが組織への訪問者に表示される場合が含まれます。

U1.1.9.1.2 攻撃者は、双眼鏡や無人航空機などの追加の技術的手段を使用し、窓から資格情報が入力されるのを目撃しました。
U1.1.9.2。 攻撃者は、キーボードとコンピュータ システム ユニットが無線インターフェイス (Bluetooth など) を介して接続されている場合、それらの間の無線通信から資格情報を抽出しました。
U1.1.9.3。 攻撃者は、偽の電磁放射と干渉 (PEMIN) のチャネルを通じて資格情報を漏洩することにより、資格情報を傍受しました。
説明U1.1.9.3。
攻撃の例 ここで и ここで.

U1.1.9.4。 攻撃者は、秘密裏に情報を取得するように設計された特別な技術的手段 (STS) を使用して、キーボードからの資格情報の入力を傍受しました。
説明U1.1.9.4。
例 デバイス.

U1.1.9.5。 攻撃者は、キーボードからの資格情報の入力を傍受しました。
ユーザーのキーストロークプロセスによって変調された Wi-Fi 信号の分析。
説明U1.1.9.5。
例 攻撃.

U1.1.9.6。 攻撃者は、キーストロークの音を分析することで、キーボードからの資格情報の入力を傍受しました。
説明U1.1.9.6。
例 攻撃.

U1.1.9.7。 攻撃者は、加速度計の読み取り値を分析することで、モバイル デバイスのキーボードからの資格情報の入力を傍受しました。
説明U1.1.9.7。
例 攻撃.

U1.1.10。 <…>、以前にクライアントに保存されました。
説明U1.1.10。
たとえば、ユーザーは特定のサイトにアクセスするためにブラウザにログイン名とパスワードを保存できます。

U1.1.11。 攻撃者は、ユーザー アクセスを取り消すプロセスの不備により、資格情報を侵害しました。
説明U1.1.11。
たとえば、ユーザーが解雇された後も、そのアカウントはブロックされずに残りました。

U1.2。 <…> アクセス制御システムの脆弱性を悪用します。

U2。 情報システムにおけるユーザー権限の不正な昇格

分解
U2.1 <…> ユーザー権限に関する情報を含むデータに不正な変更を加える。

U2.2 <…> アクセス制御システムの脆弱性を利用。

U2.3。 <…> ユーザー アクセス管理プロセスの欠陥が原因です。
説明U2.3。
例 1. ビジネス上の理由から、ユーザーに必要以上のアクセス権が仕事のために与えられました。
例 2: ユーザーが別の役職に異動した後、以前に付与されたアクセス権は取り消されませんでした。

典型的な脅威モデル。 統合モジュール

脅威モデル（スコープ）が適用される保護オブジェクト

統合モジュールは、情報システム間の情報交換を組織化するために設計された情報インフラストラクチャ オブジェクトのセットです。

企業ネットワークでは、ある情報システムを別の情報システムから明確に分離することが常に可能であるとは限らないという事実を考慮すると、統合モジュールは、XNUMX つの情報システム内のコンポーネント間の接続リンクと考えることもできます。

アーキテクチャ
統合モジュールの一般化された図は次のようになります。

建築要素の説明:

• 「Exchangeサーバー(SO)」 – 別の情報システムとデータを交換する機能を実行する情報システムのノード/サービス/コンポーネント。
• 「メディエーター」 – 情報システム間の相互作用を組織化するために設計されたノード/サービスですが、情報システムの一部ではありません。
  例 「仲介者」 電子メール サービス、エンタープライズ サービス バス (エンタープライズ サービス バス/SoA アーキテクチャ)、サードパーティのファイル サーバーなどが存在する場合があります。 一般に、統合モジュールには「仲介者」を含めることはできません。
• 「データ処理ソフト」 – データ交換プロトコルとフォーマット変換を実装する一連のプログラム。
  たとえば、UFEBS 形式から ABS 形式へのデータの変換、送信中のメッセージ ステータスの変更などです。
• "ネットワーク接続" 標準の「ネットワーク接続」脅威モデルで説明されているオブジェクトに対応します。 上の図に示されているネットワーク接続の一部は存在しない場合があります。

統合モジュールの例

スキーム 1. サードパーティのファイルサーバーを介した ABS と AWS KBR の統合

支払いを実行するには、権限のある銀行の従業員がコア バンキング システムから電子支払い文書をダウンロードし、ファイル サーバー上のネットワーク フォルダー (...SHARE) 上のファイル (SQL ダンプなどの独自の形式) に保存します。 次に、このファイルはコンバータ スクリプトを使用して UFEBS 形式のファイル セットに変換され、CBD ワークステーションによって読み取られます。
この後、権限を与えられた従業員、つまり自動化された職場 KBR のユーザーが、受信したファイルを暗号化して署名し、ロシア銀行の支払いシステムに送信します。

ロシア銀行から支払いを受け取ると、KBR の自動化された作業場がその支払いを復号化して電子署名をチェックし、その後ファイル サーバー上に UFEBS 形式の一連のファイルの形式で記録します。 支払い文書を ABS にインポートする前に、コンバータ スクリプトを使用して UFEBS 形式から ABS 形式に変換されます。

このスキームでは、ABS は XNUMX 台の物理サーバー上で動作し、KBR ワークステーションは専用コンピュータ上で動作し、コンバータ スクリプトはファイル サーバー上で動作すると仮定します。

考慮されている図のオブジェクトと統合モジュール モデルの要素の対応:
「ABS側からサーバーを交換する」 – ABS サーバー。
「AWS KBR側からのExchangeサーバー」 – コンピュータワークステーション KBR。
「メディエーター」 – サードパーティのファイル サーバー。
「データ処理ソフト」 – コンバータスクリプト。

スキーム 2. AWS KBR 上に支払いを含む共有ネットワークフォルダーを配置する場合の ABS と AWS KBR の統合

すべてはスキーム 1 と似ていますが、別個のファイル サーバーは使用されず、代わりに電子支払書類を含むネットワーク フォルダー (...SHARE) が CBD のワークステーションを備えたコンピューター上に配置されます。 コンバータ スクリプトは CBD ワークステーションでも動作します。

考慮されている図のオブジェクトと統合モジュール モデルの要素の対応:
スキーム 1 と似ていますが、 「メディエーター」 使用されていない。

スキーム 3. IBM WebSphere MQ を介した ABS と自動化されたワークプレイス KBR-N の統合、および「ABS 側」での電子文書の署名

ABS は、CIPF SCAD シグネチャによってサポートされていないプラットフォームで動作します。 送信される電子文書の署名は、特別な電子署名サーバー (ES サーバー) 上で実行されます。 同じサーバーが、ロシア銀行から受信した書類の電子署名をチェックします。

ABS は、独自の形式で支払い書類を含むファイルを ES サーバーにアップロードします。
ES サーバーは、コンバーター スクリプトを使用してファイルを UFEBS 形式の電子メッセージに変換し、その後電子メッセージに署名して IBM WebSphere MQ に送信します。

KBR-N ワークステーションは IBM WebSphere MQ にアクセスし、そこから署名済みの支払いメッセージを受信します。その後、権限のある従業員 (KBR ワークステーションのユーザー) がメッセージを暗号化し、ロシア銀行の支払いシステムに送信します。

ロシア銀行から支払いを受け取ると、自動化されたワークプレイス KBR-N が支払いを復号化し、電子署名を検証します。 正常に処理された支払いは、復号化および署名された UFEBS 形式の電子メッセージの形で IBM WebSphere MQ に転送され、そこから電子署名サーバーによって受信されます。

電子署名サーバーは、受け取った支払いの電子署名を検証し、ABS 形式のファイルに保存します。 この後、許可された従業員 (ABS ユーザー) は、結果として得られたファイルを所定の方法で ABS にアップロードします。

考慮されている図のオブジェクトと統合モジュール モデルの要素の対応:
「ABS側からサーバーを交換する」 – ABS サーバー。
「AWS KBR側からのExchangeサーバー」 — コンピュータワークステーション KBR。
「メディエーター」 – ES サーバーと IBM WebSphere MQ。
「データ処理ソフト」 – スクリプト コンバータ、ES サーバー上の CIPF SCAD 署名。

スキーム 4. 専用の Exchange サーバーが提供する API を介した RBS サーバーとコア バンキング システムの統合

銀行がいくつかのリモート バンキング システム (RBS) を使用していると仮定します。

• 個人向けの「インターネット クライアント バンク」(IKB FL);
• 法人向けの「インターネット クライアント バンク」(IKB LE)。

情報セキュリティを確保するために、ABS とリモート バンキング システムの間のすべてのやり取りは、ABS 情報システムのフレームワーク内で動作する専用の交換サーバーを通じて実行されます。

次に、IKB LE の RBS システムと ABS の間の相互作用のプロセスを検討します。
RBS サーバーは、クライアントから正式に認証された支払い命令を受信すると、それに基づいて ABS 内に対応する文書を作成する必要があります。 これを行うには、API を使用して情報を交換サーバーに送信し、交換サーバーがデータを ABS に入力します。

クライアントの口座残高が変化すると、ABS は電子通知を生成し、交換サーバーを使用してリモート バンキング サーバーに送信します。

考慮されている図のオブジェクトと統合モジュール モデルの要素の対応:
「RBS 側からの Exchange サーバー」 – IKB YULのRBSサーバー。
「ABS側からサーバーを交換する」 – 交換サーバー。
「メディエーター」 - ない。
「データ処理ソフト」 – Exchange サーバー API の使用を担当する RBS サーバー コンポーネント、コア バンキング API の使用を担当する Exchange サーバー コンポーネント。

トップレベルのセキュリティ脅威

分解
U1。 攻撃者による統合モジュールを介した偽情報の注入。

U1。 統合モジュールを介した攻撃者による虚偽の情報の注入

分解
U1.1。 ネットワーク接続経由​​で送信される場合の正当なデータの不正な変更:
U1.1.1 リンク: 「典型的な脅威モデル。 ネットワーク接続。 U2。 送信データの不正な改ざん」.

U1.2。 正規の交換参加者に代わって、通信チャネルを介して虚偽のデータを送信する:
U1.1.2 リンク: 「典型的な脅威モデル。 ネットワーク接続。 U3。 送信データの著作権侵害」.

U1.3。 Exchange サーバーまたは仲介者での処理中の正当なデータの不正な変更:
U1.3.1。 リンク： 「典型的な脅威モデル。 クライアントサーバーアーキテクチャに基づいて構築された情報システム。 U2。 情報システムのサーバー部分による処理中の保護された情報の不正な変更」.

U1.4。 正当な Exchange 参加者に代わって、Exchange サーバーまたは仲介者上に虚偽のデータを作成する場合:
U1.4.1。 リンク： 「典型的な脅威モデル。 クライアントサーバーアーキテクチャに基づいて構築された情報システム。 U1。 正規のユーザーに代わって攻撃者によって不正なアクションが実行される。」

U1.5。 データ処理ソフトウェアを使用して処理される場合のデータの不正な変更:
U1.5.1。 <…> 攻撃者がデータ処理ソフトウェアの設定 (構成) を不正に変更したため。
U1.5.2。 <…> 攻撃者がデータ処理ソフトウェアの実行可能ファイルに不正な変更を加えたことが原因です。
U1.5.3。 <…> 攻撃者によるデータ処理ソフトウェアの対話型制御が原因です。

典型的な脅威モデル。 暗号情報保護システム

脅威モデル（スコープ）が適用される保護オブジェクト

保護の対象となるのは、情報システムのセキュリティを確保するために使用される暗号情報保護システムです。

アーキテクチャ
情報システムの基礎は、その目的の機能を実装するアプリケーション ソフトウェアです。

暗号化保護は通常、アプリケーション ソフトウェアのビジネス ロジックから暗号化プリミティブを呼び出すことによって実装されます。暗号化プリミティブは、特殊なライブラリ (暗号コア) にあります。

暗号化プリミティブには、次のような低レベルの暗号化関数が含まれます。

• データのブロックを暗号化/復号化します。
• データブロックの電子署名を作成/検証します。
• データブロックのハッシュ関数を計算します。
• キー情報を生成/ロード/アップロードします。
• 等

アプリケーション ソフトウェアのビジネス ロジックは、暗号化プリミティブを使用して高度な機能を実装します。

• 選択した受信者のキーを使用してファイルを暗号化します。
• 安全なネットワーク接続を確立します。
• 電子署名のチェック結果を通知する。
• 等々。

ビジネス ロジックと暗号コアの相互作用は次のように実行できます。

• 暗号カーネルの動的ライブラリ (Windows の場合は .DLL、Linux の場合は .SO) から暗号プリミティブを呼び出すビジネス ロジックによって直接。
• MS Crypto API、Java Cryptography Architecture、PKCS#11 などの暗号インターフェイス - ラッパーを介して直接。この場合、ビジネス ロジックは暗号インターフェイスにアクセスし、呼び出しを対応する暗号コアに変換します。このケースは暗号プロバイダーと呼ばれます。 暗号化インターフェイスを使用すると、アプリケーション ソフトウェアが特定の暗号化アルゴリズムから抽象化され、より柔軟になることができます。

暗号コアを構成するには、次の XNUMX つの典型的なスキームがあります。

スキーム 1 – モノリシック暗号コア


スキーム 2 – 暗号コアの分割


上の図の要素は、XNUMX 台のコンピューター上で実行される個々のソフトウェア モジュール、またはコンピューター ネットワーク内で対話するネットワーク サービスのいずれかになります。

スキーム 1 に従って構築されたシステムを使用する場合、アプリケーション ソフトウェアと暗号コアは、暗号化ツール (SFC) の単一オペレーティング環境内で動作します。たとえば、同じコンピュータ上で同じオペレーティング システムを実行します。 システム ユーザーは、原則として、悪意のあるコードを含む他のプログラムを同じオペレーティング環境内で実行できます。 このような状況では、秘密暗号鍵が漏洩する重大な危険性があります。

リスクを最小限に抑えるために、暗号コアが 2 つの部分に分割されるスキーム XNUMX が使用されます。

1. 最初の部分は、アプリケーション ソフトウェアとともに、悪意のあるコードに感染するリスクがある信頼できない環境で動作します。 この部分を「ソフトウェア部分」と呼びます。
2. XNUMX 番目の部分は、秘密キー ストレージを含む専用デバイスの信頼された環境で動作します。 以降、この部分を「ハードウェア」と呼びます。

暗号コアのソフトウェア部分とハードウェア部分への分割は非常に恣意的です。 分割された暗号コアを備えたスキームに従って構築されたシステムが市場にありますが、その「ハードウェア」部分は仮想マシン イメージ、つまり仮想 HSM (例).

暗号コアの両方の部分の相互作用は、秘密暗号キーがソフトウェア部分に転送されない方法で行われるため、悪意のあるコードを使用して盗むことはできません。

インタラクション インターフェイス (API) と、暗号コアによってアプリケーション ソフトウェアに提供される暗号化プリミティブのセットは、どちらの場合も同じです。 違いは実装方法にあります。

したがって、分割された暗号コアを備えたスキームを使用する場合、ソフトウェアとハ​​ードウェアの相互作用は次の原則に従って実行されます。

1. 秘密キーの使用を必要としない暗号化プリミティブ (ハッシュ関数の計算、電子署名の検証など) はソフトウェアによって実行されます。
2. 秘密キーを使用する暗号化プリミティブ (電子署名の作成、データの復号化など) はハードウェアによって実行されます。

電子署名の作成の例を使用して、分割された暗号コアの動作を説明してみましょう。

1. ソフトウェア部分は署名されたデータのハッシュ関数を計算し、暗号コア間の交換チャネルを介してこの値をハードウェアに送信します。
2. ハードウェア部分は、秘密キーとハッシュを使用して電子署名の値を生成し、それを交換チャネル経由でソフトウェア部分に送信します。
3. ソフトウェア部は受け取った値をアプリケーションソフトウェアに返します。

電子署名の正当性をチェックする機能

受信側が電子署名されたデータを受け取る場合、いくつかの検証手順を実行する必要があります。 電子署名のチェックで肯定的な結果が得られるのは、検証のすべての段階が正常に完了した場合のみです。

ステージ 1. データの完全性とデータの作成者の制御。

ステージの内容。 データの電子署名は、適切な暗号化アルゴリズムを使用して検証されます。 この段階が正常に完了すると、データが署名された瞬間から変更されていないこと、また電子署名を検証するための公開鍵に対応する秘密鍵を使用して署名が行われたことを示します。
ステージの場所: クリプトコア。

ステージ 2. 署名者の公開鍵の信頼性の制御と電子署名の秘密鍵の有効期間の制御。
ステージの内容。 このステージは XNUMX つの中間サブステージで構成されます。 XNUMX つ目は、データの署名時に電子署名を検証するための公開鍵が信頼されたかどうかを判断することです。 XNUMX つ目は、データの署名時に電子署名の秘密キーが有効であったかどうかを判断します。 一般に、これらのキーの有効期間は一致しない場合があります (たとえば、電子署名検証キーの適格な証明書の場合)。 署名者の公開鍵に対する信頼を確立する方法は、対話当事者が採用する電子文書管理のルールによって決定されます。
ステージの場所: アプリケーション ソフトウェア/暗号コア。

ステージ 3. 署名者の権限の制御。
ステージの内容。 電子文書管理の確立されたルールに従って、署名者が保護されたデータを証明する権利を持っているかどうかがチェックされます。 例として、権限違反の状況を挙げてみましょう。 すべての従業員が電子署名を持っている組織があるとします。 社内の電子文書管理システムはマネージャーから注文を受け取りますが、倉庫管理者の電子署名で署名されます。 したがって、そのような文書は合法であるとは考えられません。
ステージの場所: アプリケーションソフトウェア。

保護の対象を説明する際の前提条件

1. 情報伝送チャネルは、鍵交換チャネルを除き、アプリケーション ソフトウェア、API、暗号コアも通過します。
2. 公開キーおよび (または) 証明書の信頼性に関する情報、および公開キーの所有者の権限に関する情報は、公開キー ストアにあります。
3. アプリケーション ソフトウェアは、暗号カーネルを通じて公開キー ストアと連携します。

CIPFを使用して保護された情報システムの例

前に示した図を説明するために、仮想の情報システムを考え、その上のすべての構造要素を強調表示してみましょう。

情報システムの説明

2016 つの組織は、法的に重要な電子文書管理 (EDF) を相互に導入することを決定しました。 そのために、文書は電子メールで送信され、同時に文書は暗号化され、適格な電子署名で署名される必要があると規定する契約を締結しました。 Microsoft Office XNUMX パッケージの Office プログラムはドキュメントの作成と処理のツールとして使用する必要があり、CIPF CryptoPRO と暗号化ソフトウェア CryptoARM は暗号化保護の手段として使用する必要があります。

組織のインフラストラクチャの説明 1

組織 1 は、CIPF CryptoPRO および CryptoARM ソフトウェアをユーザーのワークステーション (物理コンピュータ) にインストールすることを決定しました。 暗号化キーと電子署名キーは ruToken キー メディアに保存され、取得可能なキー モードで動作します。 ユーザーは自分のコンピュータ上で電子ドキュメントをローカルに作成し、ローカルにインストールされた電子メール クライアントを使用してそれらを暗号化し、署名して送信します。

組織のインフラストラクチャの説明 2

組織 2 は、暗号化と電子署名の機能を専用の仮想マシンに移行することを決定しました。 この場合、すべての暗号化操作は自動的に実行されます。

これを行うために、専用の仮想マシン上に XNUMX つのネットワーク フォルダー「...In」、「...Out」が編成されます。 取引相手から受信した開いているファイルは、ネットワーク フォルダー「…In」に自動的に配置されます。 これらのファイルは復号化され、電子署名が検証されます。

ユーザーは、暗号化、署名して取引相手に送信する必要があるファイルを「…Out」フォルダーに配置します。 ユーザーは自分のワークステーション上でファイルを自分で準備します。
暗号化および電子署名機能を実行するために、CIPF CryptoPRO、CryptoARM ソフトウェア、電子メール クライアントが仮想マシンにインストールされます。 仮想マシンのすべての要素の自動管理は、システム管理者が開発したスクリプトを使用して実行されます。 スクリプトの動作はログ ファイルに記録されます。

電子署名の暗号キーは、取得不可能な JaCarta GOST キーを持つトークンに配置され、ユーザーはこれをローカル コンピューターに接続します。

トークンは、ユーザーのワークステーションと仮想マシンにインストールされた専用の USB-over-IP ソフトウェアを使用して仮想マシンに転送されます。

組織 1 のユーザーのワークステーションのシステム クロックは手動で調整されます。 組織 2 の専用仮想マシンのシステム クロックはハイパーバイザー システム クロックと同期され、さらにインターネット経由でパブリック タイム サーバーと同期されます。

CIPFの構造要素の特定
IT インフラストラクチャに関する上記の説明に基づいて、CIPF の構造要素を強調表示し、表に書き出します。

表 - CIPF モデル要素と情報システム要素の対応

商品名
組織1
組織2

アプリケーションソフトウェア
CryptoARM ソフトウェア
CryptoARM ソフトウェア

暗号コアのソフトウェア部分
CIPF クリプトプロ CSP
CIPF クリプトプロ CSP

暗号コアハードウェア
ノー
ジャカルタGOST

API
MS 暗号 API
MS 暗号 API

公開鍵ストア
ユーザーのワークステーション:
- HDD;
- 標準の Windows 証明書ストア。
ハイパーバイザー:
- HDD。

仮想マシン:
- HDD;
- 標準の Windows 証明書ストア。

秘密鍵のストレージ
取得可能なキー モードで動作する ruToken キー キャリア
JaCarta GOST キーキャリアは取り外し不可能なキーモードで動作します

公開鍵交換チャネル
ユーザーのワークステーション:
- ラム。

ハイパーバイザー:
- ラム。

仮想マシン:
- ラム。

秘密鍵交換チャネル
ユーザーのワークステーション:
— USBバス;
- ラム。
ノー

暗号コア間の交換チャネル
欠落しています (暗号コアハードウェアがありません)
ユーザーのワークステーション:
— USBバス;
- ラム;
— USB-over-IP ソフトウェア モジュール。
- ネットワークインターフェース。

組織の社内ネットワーク ２．

ハイパーバイザー:
- ラム;
- ネットワークインターフェース。

仮想マシン:
- ネットワークインターフェース;
- ラム;
— USB-over-IP ソフトウェア モジュール。

オープンデータチャネル
ユーザーのワークステーション:
— 入出力手段;
- ラム;
- HDD。
ユーザーのワークステーション:
— 入出力手段;
- ラム;
- HDD;
- ネットワークインターフェース。

組織の社内ネットワーク ２．

ハイパーバイザー:
- ネットワークインターフェース;
- ラム;
- HDD。

仮想マシン:
- ネットワークインターフェース;
- ラム;
- HDD。

安全なデータ交換チャネル
インターネット。

組織の社内ネットワーク ２．

ユーザーのワークステーション:
- HDD;
- ラム;
- ネットワークインターフェース。

インターネット。

組織の社内ネットワーク ２．

ハイパーバイザー:
- ネットワークインターフェース;
- ラム;
- HDD。

仮想マシン:
- ネットワークインターフェース;
- ラム;
- HDD。

タイムチャンネル
ユーザーのワークステーション:
— 入出力手段;
- ラム;
- システムタイマー。

インターネット。
組織の企業ネットワーク 2、

ハイパーバイザー:
- ネットワークインターフェース;
- ラム;
- システムタイマー。

仮想マシン:
- ラム;
- システムタイマー。

制御コマンド送信チャネル
ユーザーのワークステーション:
— 入出力手段;
- ラム。

(CryptoARM ソフトウェアのグラフィカル ユーザー インターフェイス)

仮想マシン:
- ラム;
- HDD。

(自動化スクリプト)

作業結果を受け取るチャネル
ユーザーのワークステーション:
— 入出力手段;
- ラム。

(CryptoARM ソフトウェアのグラフィカル ユーザー インターフェイス)

仮想マシン:
- ラム;
- HDD。

(自動化スクリプトのログ ファイル)

トップレベルのセキュリティ脅威

説明

脅威を分解する際の前提条件:

1. 強力な暗号化アルゴリズムが使用されています。
2. 暗号化アルゴリズムは、正しい動作モードで安全に使用されます (例: ECB 大量のデータの暗号化には使用されず、キーの許容負荷などが考慮されます)。
3. 攻撃者は、使用されるアルゴリズム、プロトコル、公開鍵をすべて知っています。
4. 攻撃者はすべての暗号化されたデータを読み取ることができます。
5. 攻撃者はシステム内のあらゆるソフトウェア要素を再現できます。

分解

U1。 秘密暗号キーの侵害。
U2。 正規の送信者に代わって偽のデータを暗号化します。
U3。 データの正当な受信者ではない人 (攻撃者) による、暗号化されたデータの復号化。
U4。 虚偽のデータに基づく正当な署名者の電子署名の作成。
U5。 偽造データの電子署名を検査して肯定的な結果を得る。
U6。 電子文書の流れを整理する際の問題による、電子文書の実行のための誤った受け入れ。
U7。 CIPF による処理中の保護されたデータへの不正アクセス。

U1。 秘密暗号キーの侵害

U1.1。 秘密鍵ストアから秘密鍵を取得します。

U1.2。 暗号化ツールの動作環境内のオブジェクトから秘密鍵を取得します。この環境内に秘密鍵が一時的に存在する可能性があります。
説明U1.2。

秘密キーを一時的に保存できるオブジェクトには次のものがあります。

1. RAM、
2. 一時ファイル、
3. ファイルを交換し、
4. 休止状態ファイル、
5. 仮想マシンの「ホット」状態のスナップショット ファイル (一時停止された仮想マシンの RAM の内容のファイルを含む)。

U1.2.1。 RAM モジュールをフリーズし、削除してデータを読み取ることにより、作業中の RAM から秘密キーを抽出します (フリーズ攻撃)。
説明U1.2.1。
例 攻撃.

U1.3。 秘密鍵交換チャネルから秘密鍵を取得します。
説明U1.3。
この脅威の実装例を示します。 以下.

U1.4。 暗号コアの不正な変更。その結果、秘密鍵が攻撃者に知られることになります。

U1.5。 技術情報漏洩チャネル (TCIL) の使用による秘密キーの侵害。
説明U1.5。
例 攻撃.

U1.6。 情報 (「バグ」) を秘密裏に取得するために設計された特別な技術的手段 (STS) の使用の結果として生じる秘密キーの侵害。

U1.7。 秘密キーが CIPF の外に保管されている間に侵害される。
説明U1.7。
たとえば、ユーザーは自分のキー メディアをデスクトップの引き出しに保存しており、そこから攻撃者が簡単に取得できます。

U2。 正規の送信者に代わって偽のデータを暗号化する

説明
この脅威は、送信者認証を伴うデータ暗号化スキームに対してのみ考慮されます。 このようなスキームの例は標準化勧告に示されています。 R 1323565.1.004-2017 「情報技術。 暗号化情報の保護。 公開鍵に基づく認証を使用して公開鍵を生成するスキーム」。 他の暗号化スキームの場合、暗号化は受信者の公開キーで実行され、一般に攻撃者に知られているため、この脅威は存在しません。

分解
U2.1。 送信者の秘密キーを侵害する:
U2.1.1。 リンク： 「典型的な脅威モデル。 暗号情報保護システム。У1. 秘密暗号キーの侵害」.

U2.2。 オープンデータ交換チャネルでの入力データの置換。
注U2.2。
この脅威の実装例を以下に示します。 ここで и ここで.

U3。 データの正当な受信者ではない人物（攻撃者）による暗号化データの復号化

分解
U3.1。 暗号化されたデータの受信者の秘密キーが侵害される。
U3.1.1 リンク: 「典型的な脅威モデル。 暗号化情報保護システム。 U1。 秘密暗号キーの侵害」.

U3.2。 安全なデータ交換チャネルでの暗号化されたデータの置き換え。

U4。 虚偽のデータに基づいて正当な署名者の電子署名を作成する

分解
U4.1。 正当な署名者の電子署名の秘密キーが侵害される。
U4.1.1 リンク: 「典型的な脅威モデル。 暗号化情報保護システム。 U1。 秘密暗号キーの侵害」.

U4.2。 オープンデータ交換チャネルでの署名付きデータの置換。
U4.2に注意してください。
この脅威の実装例を以下に示します。 ここで и ここで.

U5。 偽造データの電子署名を検証して肯定的な結果を得る

分解
U5.1。 攻撃者は、作業結果を送信するチャネル内で、電子署名の検査結果が否定的であるというメッセージを傍受し、肯定的結果を示すメッセージに置き換える。

U5.2。 攻撃者は証明書への署名の信頼を攻撃します (SCRIPT - すべての要素が必須です):
U5.2.1。 攻撃者は電子署名用の公開キーと秘密キーを生成します。 システムが電子署名キー証明書を使用する場合、システムは、メッセージを偽造するデータの意図された送信者の証明書に可能な限り類似した電子署名証明書を生成します。
U5.2.2。 攻撃者は公開キー ストアに不正な変更を加え、生成した公開キーに必要なレベルの信頼と権限を与えます。
U5.2.3。 攻撃者は、事前に生成した電子署名キーを使用して偽のデータに署名し、それを安全なデータ交換チャネルに挿入します。

U5.3。 攻撃者は、法的署名者の有効期限が切れた電子署名キーを使用して攻撃を実行します (SCRIPT - すべての要素が必須です):
U5.3.1。 攻撃者は、正当な送信者の電子署名の有効期限が切れた (現在は有効ではない) 秘密キーを侵害します。
U5.3.2。 攻撃者は、時刻送信チャネル内の時刻を、侵害されたキーがまだ有効であった時刻に置き換えます。
U5.3.3。 攻撃者は、以前に漏洩した電子署名キーを使用して偽のデータに署名し、それを安全なデータ交換チャネルに挿入します。

U5.4。 攻撃者は、法的署名者の漏洩した電子署名キーを使用して攻撃を実行します (SCRIPT - すべての要素が必須です):
U5.4.1。 攻撃者は公開キー ストアのコピーを作成します。
U5.4.2。 攻撃者は、正当な送信者の XNUMX 人の秘密キーを侵害します。 彼は侵害に気づき、キーを取り消し、キーの取り消しに関する情報が公開キー ストアに配置されます。
U5.4.3。 攻撃者は、公開キー ストアを以前にコピーしたものに置き換えます。
U5.4.4。 攻撃者は、以前に漏洩した電子署名キーを使用して偽のデータに署名し、それを安全なデータ交換チャネルに挿入します。

U5.5。 <…> 電子署名検証の第 2 段階と第 3 段階の実装にエラーがあったため:
説明U5.5。
この脅威の実装例は次のとおりです。 以下.

U5.5.1。 CRL または OCSP チェックを行わずに、電子署名キー証明書の信頼性を、署名に使用された証明書の信頼性の有無のみによってチェックします。
説明U5.5.1。
実装例 脅威.

U5.5.2。 証明書の信頼チェーンを構築する際、証明書の発行機関は分析されません
説明U5.5.2。
SSL/TLS 証明書に対する攻撃の例。
攻撃者は電子メール用の正規の証明書を購入しました。 次に、不正サイト証明書を作成し、証明書で署名しました。 資格情報がチェックされない場合、信頼チェーンをチェックすると正しいことが判明し、それに応じて不正な証明書も正しいことが判明します。

U5.5.3。 証明書信頼チェーンを構築する場合、中間証明書の失効はチェックされません。

U5.5.4。 CRL は、認証局が発行するよりも更新頻度が低くなります。

U5.5.5。 電子署名を信頼するかどうかの決定は、証明書のステータスに関する OCSP 応答が受信される前に行われ、署名の生成時以降、または署名生成後の次の CRL より前に行われた要求に応じて送信されます。
説明U5.5.5。
ほとんどの CA の規制では、証明書の失効時刻は、証明書の失効に関する情報を含む最も近い CRL の発行時刻とみなされます。

U5.5.6。 署名付きデータを受信する場合、送信者の証明書はチェックされません。
説明U5.5.6。
攻撃の例。 SSL 証明書に関連して: 呼び出されたサーバーのアドレスと証明書の CN フィールドの値の対応がチェックされない場合があります。
攻撃の例。 攻撃者は、支払いシステム参加者の XNUMX 人の電子署名キーを侵害しました。 その後、彼らは別の参加者のネットワークをハッキングし、その参加者に代わって、侵害されたキーで署名された支払い文書を支払いシステムの決済サーバーに送信しました。 サーバーが信頼性を分析するだけでコンプライアンスをチェックしない場合、不正な文書は正規のものとみなされます。

U6。 電子文書の流れを整理する際の問題による、電子文書の実行のための誤った受け入れ。

分解
U6.1。 受信側は受信した文書の重複を検出しません。
説明U6.1。
攻撃の例。 攻撃者は、暗号化で保護されている場合でも、受信者に送信されている文書を傍受し、安全なデータ送信チャネルを介して繰り返し送信する可能性があります。 受信者が重複を識別しない場合、受信したすべての文書は別の文書として認識され、処理されます。

U7。 CIPF による処理中の保護データへの不正アクセス

分解

U7.1。 <…> サイドチャネルを介した情報漏洩（サイドチャネル攻撃）によるもの。
説明U7.1。
例 攻撃.

U7.2。 <…> CIPF で処理される情報への不正アクセスに対する保護が無効化されるため:
U7.2.1。 CIPF のドキュメントに記載されている要件に違反した CIPF の操作。

U7.2.2。 <…>、以下に脆弱性が存在するために実行されました。
U7.2.2.1。 <…> 不正アクセスに対する保護手段。
U7.2.2.2。 <…> CIPF 自体。
U7.2.2.3。 <…> 暗号化ツールの動作環境。

攻撃の例

以下で説明するシナリオには明らかに情報セキュリティ エラーが含まれており、起こり得る攻撃を説明するためにのみ使用されます。

シナリオ 1. 脅威 U2.2 および U4.2 の実装の例。

オブジェクトの説明


AWS KBR ソフトウェアと CIPF SCAD 署名は、コンピューター ネットワークに接続されていない物理コンピューターにインストールされます。 FKN vdToken は、取り外し不可能なキーを操作するモードでキー キャリアとして使用されます。

決済規則では、決済専門家が職場のコンピュータから特別な安全なファイル サーバーから平文の電子メッセージ (旧 KBR ワークステーションのスキーム) をダウンロードし、転送可能な USB フラッシュ ドライブに書き込んで KBR ワークステーションに転送することを想定しています。暗号化されて署名される場所。 この後、専門家は安全な電子メッセージを隔離された媒体に転送し、職場のコンピュータを介してファイル サーバーに書き込み、そこから UTA に送信され、さらにロシア銀行の決済システムに送信されます。

この場合、オープン データと保護されたデータを交換するチャネルには、ファイル サーバー、専門家の職場のコンピューター、および疎外されたメディアが含まれます。

アタック
不正な攻撃者は、専門家の職場のコンピュータに遠隔制御システムをインストールし、転送可能な媒体に支払い命令 (電子メッセージ) を書き込む際に、そのうちの XNUMX つの内容をクリア テキストに置き換えます。 専門家は、支払い注文を KBR 自動化ワークプレイスに転送し、置き換えに気付かずに署名し、暗号化します (たとえば、飛行機内での多数の支払い注文、疲労などによる)。 この後、偽の支払い注文は技術チェーンを通過して、ロシア銀行の支払いシステムに入ります。

シナリオ 2. 脅威 U2.2 および U4.2 の実装の例。

オブジェクトの説明


ワークステーション KBR、SCAD 署名、および接続されたキー キャリア FKN vdToken がインストールされたコンピューターは、担当者がアクセスすることなく専用の部屋で動作します。
計算スペシャリストは、RDP プロトコルを介してリモート アクセス モードで CBD ワークステーションに接続します。

アタック
攻撃者は詳細を傍受し、これを使用して計算専門家が CBD ワークステーションに接続して操作します (たとえば、コンピューター上の悪意のあるコードを通じて)。 次に、彼らは彼の代わりに接続し、偽の支払い命令をロシア銀行の支払いシステムに送信します。

シナリオ 3. 脅威実装の例 U1.3。

オブジェクトの説明


新しいスキーム (AWS KBR-N) の ABS-KBR 統合モジュールを実装するための仮説的なオプションの XNUMX つを考えてみましょう。このスキームでは、送信ドキュメントの電子署名が ABS 側で行われます。 この場合、ABS は CIPF SKAD 署名でサポートされていないオペレーティング システムに基づいて動作し、それに応じて暗号化機能が別の仮想マシン (「ABS-KBR」統合) に転送されると想定します。モジュール。
取得可能キー モードで動作する通常の USB トークンがキー キャリアとして使用されます。 キーメディアをハイパーバイザーに接続するときに、システムに空き USB ポートがないことが判明したため、ネットワーク USB ハブ経由で USB トークンを接続し、仮想サーバーに USB-over-IP クライアントをインストールすることにしました。ハブと通信するマシン。

アタック
攻撃者は、USB ハブとハイパーバイザー間の通信チャネルから電子署名の秘密キーを傍受しました (データはクリア テキストで送信されました)。 秘密キーを入手した攻撃者は、偽の支払い注文を生成し、電子署名で署名し、実行のために KBR-N 自動化ワークプレイスに送信しました。

シナリオ 4. 脅威 U5.5 の実装例。

オブジェクトの説明
前のシナリオと同じ回路を考えてみましょう。 KBR-N ワークステーションから送信された電子メッセージは最終的に…SHAREIn フォルダーに到達し、KBR-N ワークステーションに送信され、さらにロシア銀行の決済システムに送信された電子メッセージは…SHAREout に送られると仮定します。
また、統合モジュールを実装する場合、失効した証明書のリストは暗号キーが再発行された場合にのみ更新され、…SHAREIn フォルダーで受信された電子メッセージは、公開キーの整合性制御と信頼制御についてのみチェックされると想定します。電子署名。

アタック

攻撃者は、前のシナリオで盗んだキーを使用して、不正なクライアントの口座への入金に関する情報を含む偽の支払い注文に署名し、それを安全なデータ交換チャネルに導入しました。 支払い命令がロシア銀行によって署名されたという証明がないため、実行が受け入れられます。

出所： habr.com