銀行のキャッシュレス支払いの情報セキュリティ。 パート3-セキュリティシステムの要件の形成

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

調査の前の部分では、銀行のキャッシュレス支払いの経済的基盤とITインフラストラクチャについて説明しました。 このパートでは、作成された情報セキュリティシステム（IS）の要件の形成に焦点を当てます。

次に考慮します：

• 営利組織の生活におけるセキュリティの役割。
• 組織の管理構造における情報セキュリティサービスの場所。
• セキュリティの実用的な側面。
• 情報セキュリティにおけるリスク管理理論の適用。
• 実装による主な脅威と潜在的な損害。
• 銀行の非現金支払いのIBシステムの必須要件の構成。

営利組織の生活におけるセキュリティの役割

現代のロシア経済環境には、さまざまな種類の組織があります。 これらは、国営企業（FSUE、MUP）、公的資金、そして最後に通常の商業組織である可能性があります。 後者と他のすべてとの主な違いは、彼らの主な目標は利益を最大化することであり、彼らが行うことはすべてこれに正確に向けられていることです。

営利団体はさまざまな方法で稼ぐことができますが、利益は常に同じ方法で決定されます-これは収入から費用を引いたものです。 さらに、セキュリティが会社の主要な活動ではない場合、それは収入を生み出しません。もしそうであれば、この活動が意味をなすためには、コストを削減する必要があります。

ビジネスのセキュリティを確保することの経済的効果は、脅威による損失を最小限に抑えるか、完全に排除することです。 しかし、保護対策の実装にも費用がかかるため、セキュリティからの真の利益は、セキュリティ脅威の実装から節約された金額に等しくなり、保護対策のコストが削減されることにも留意する必要があります。

商業銀行の所有者と彼の組織のセキュリティサービスの責任者との間で、セキュリティを確保することの経済的効果について話し合いが行われました。 この会話の本質は、組織の生活におけるセキュリティの役割と場所を最も正確に反映しています。

-セキュリティがビジネスに干渉してはなりません。
「しかし、あなたはセキュリティの代金を支払わなければならず、その不在の代金を払わなければなりません。」

理想的なセキュリティシステムは、中立化された脅威、それに費やされるリソース、およびビジネスの収益性の中間点です。

組織の管理構造における情報セキュリティサービスの場所

情報セキュリティの確保を担当する構造単位は、別の方法で呼ばれる場合があります。 部門、管理、または情報セキュリティ部門でさえも可能です。 さらに、統一のために、この構造単位を単に情報セキュリティサービス（NIB）と呼びます。

NIBを作成する理由は異なる場合があります。 私たちは2つの主なものを区別します：

1. 恐怖 。
   会社の経営陣は、コンピューター攻撃や情報漏えいが悲惨な結果につながる可能性があることを認識しており、それらを無効化する努力を行っています。
   
2. 法的要件への準拠の確保 。
   既存の法的要件は、会社にISSを確立する義務を課しており、経営陣はそれらを実装するための努力を行っています。
   

信用機関に関して、NIBの存在の必要性は次の文書に記録されています。

1. 2012年11月1日のロシア連邦政府の法令N 1119「個人データ情報システムでの処理中の個人データの保護要件の承認について」。
2. 「送金時に情報の保護を確保するための要件と、送金時に情報の保護を確保するための要件の遵守を監視するためのロシア銀行の手順に関する規制」（2012年6月9日のロシア銀行承認N 382-P） 08/14/2014）（ロシアの法務省に登録済み06/14/2012 N 24575）。
3. 「ロシア銀行の支払いシステムにおける情報保護の要件に関する規制」（2016年8月24日N 552-Pにロシア銀行により承認）（2016年12月6日N 44582にロシア法務省に登録）。
4. 暗号に関するロシア連邦セキュリティサービスのライセンスの要件： 2012年4月16日のロシア連邦 政令 No.313、2001年6月13日のFAPSIの命令No.152 （暗号化保護機関としてのISS）。
5. 主要な情報インフラストラクチャの重要なオブジェクトを持つ銀行の場合- 2017年12月21日付ロシアFSTECの命令235号。

NIBに必要な機能は、上記のドキュメントで指定されています。 おそらく、ロシアのFSBの暗号化のライセンス要件（少なくとも2人の従業員ですが、異なる部門に所属することができます）を除き、人員配置は厳密に規制されておらず、組織が独自に選択できます。 国家の規模を正当化するために、文書「ロシア連邦銀行の標準化分野における勧告」「ロシア連邦の銀行システムの組織の情報セキュリティの確保」を使用することをお勧めします。 情報セキュリティのリソースサポート「RS BR IBBS-2.7-2015」

NIBの従属の観点からは、上記のCBRの規定で規定されている1つの制限のみがあります-「情報セキュリティサービスと情報化（自動化）サービスには共通のキュレーターを置くべきではありません」、そうでなければ選択の自由は組織に残ります。 典型的なオプションを考えてみましょう。

表1

劣後	特徴
ITのNIB	1.保護の組織化は、外部の攻撃者に対してのみ可能です。 主な侵入者はIT従業員です。 ITの一部として彼に対処することは不可能です。 2.ロシア銀行の要件への違反。 3. ITとの直接対話、情報セキュリティシステムの簡単な実装
セキュリティサービスの一部としてのNIB	1.内部の攻撃者と外部の両方のアクションに対する保護。 2. SBは、セキュリティ問題に関する経営陣間の単一の対話ポイントです。 3. ITとSBのトップレベルでコミュニケーションが行われるため、ITとの相互作用の複雑さ。後者は原則として、ITの知識が最小限です。
NIBは、取締役会の議長に報告します	1. NIBには最大の権限と独自の予算があります。 2.管理委員会の議長のために、管理と対話の追加ポイントが作成されます。これには、一定の注意が必要です。 3.事件の調査における責任の分野での安全保障理事会とISSの間の可能な対立。 4.別のNIBは、安全保障理事会の権限を「政治的に」均衡させることができます。

他の構造部門や銀行の経営陣とやり取りするとき、どの組織のNIBにも共通の問題が1つあります。それは、その存在の必要性の証拠（資金調達）です。

問題は、情報セキュリティに対する中立化された脅威から節約された金額を正確に決定できないことです。 脅威が実現されていない場合、その脅威はありません。問題がないため、解決する必要はありません。

この問題を解決するために、NIBは次の2つの方法で行動できます。

1. 経済的価値を示す
   これを行うには、彼女はインシデントを追跡し、その実装による潜在的な損害を評価する必要があります。 潜在的な損害の総額は、節約されたお金と見なすことができます。 評価された損害の大きさに関する意見の相違を解決するには、まず評価方法を開発して承認することをお勧めします。
2. 内部PRに参加する
   組織の通常の従業員は通常、NIBが何をしているのかを知らず、従業員を仕事に干渉するローファーやシャーラタンと見なします。 そのため、ISSは定期的に同僚に活動の結果を通知し、情報セキュリティに対する現在の脅威について話し合い、トレーニングを実施し、意識を高める必要があります。 会社の従業員は誰でも、情報セキュリティに関連する問題が発生した場合、ISSに連絡することができ、そこで支援できると感じてください。

セキュリティの実用的な側面

情報セキュリティシステムを構築する際に考慮に入れるとともに、セキュリティを確保する実際的な側面を強調します。

1. セキュリティは、継続的で無限のプロセスです。 その助けによって達成される保護の程度は、有害な要因とそれらを中和することを目的とした努力に応じて、時間とともに変動します。
2. セキュリティは、事後、つまり脅威がすでに実現された瞬間には提供できません。 脅威を中和するには、セキュリティプロセスを開始する前に開始する必要があります。
3. 脅威のほとんどは本質的に人為的なものです。つまり、組織は何らかの形で人々によって脅かされています。 コンピューターフォレンジックが言うように：「それは盗むプログラムではなく、人々が盗む。」
4. セキュリティが確保されている人々は、脅威の中和に参加する必要があります。
   事業主であれ顧客であれ。
5. セキュリティは企業文化の派生物です。 保護対策を実装するために必要な規律は、組織の作業中に一般的な規律より高くすることはできません。

上記の中間結果を要約すると、作成された非現金支払いの情報セキュリティシステムは実用的な焦点を持ち、費用対効果が高いことに注意してください。 これらの特性を達成するための最善の助けは、リスクベースのアプローチの使用です。

リスク管理

情報セキュリティは、セキュリティの分野の1つにすぎません（経済的セキュリティ、物理的セキュリティ、防火対策など）。 情報セキュリティに対する脅威に加えて、あらゆる組織は、他の等しく重要な脅威、例えば、盗難の脅威、火災、不正な顧客側の詐欺、必須要件の違反の脅威（コンプライアンス）などの影響を受けます。

最終的な分析では、組織は、盗難、火災、またはコンピューターのハッキングなど、特定の脅威がどのような被害を受けるかを気にしません。 損失の大きさ（損傷）は重要です。

被害の規模に加えて、脅威を評価する際の重要な要素は実装の可能性です。これは、組織のビジネスプロセス、インフラストラクチャ、外部の悪意のある要因、および講じられた対策の特性に依存します。

損傷と脅威が実現する可能性を考慮した特性は、リスクと呼ばれます。
ご注意 リスクの科学的定義は、 GOST R 51897-2011で取得できます。

リスクは、例えば損傷に確率を掛けることによって定量的に測定することも、定性的に測定することもできます。 損傷も確率も定量化されない場合、定性的評価が実行されます。 この場合、リスクは値のセットとして表現できます。たとえば、損傷は「中」、確率は「高」です。

すべての脅威をリスクとして評価することで、組織は利用可能なリソースを効果的に使用して、最も重要で危険な脅威を正確に中和できます。

リスク管理は、統合された費用対効果の高い組織セキュリティシステムを構築するための主要なアプローチです。 さらに、ほとんどすべての銀行規制文書は、 バーゼル銀行監督委員会のリスク管理勧告に基づいています。

主な脅威とその実装による潜在的な損害の評価

銀行のキャッシュレス支払いの活動に内在する主な脅威を特定し、その実装による最大の損害を判断します。

表2。

いや	脅威	考えられる最大の損傷
1	活動の終了（ロングストップ）	銀行免許の取消し
2	現金の盗難	口座の現金残高
3	適用される法律およびロシア銀行との合意によって確立された活動に対する必須要件の違反	銀行免許の取消し

ここで、分析されたアクティビティの構造には、一連のビジネスプロセスが含まれます。

• パートナー銀行およびロシア連邦中央銀行との特派員関係の実施。
• 顧客との和解。

将来的には、ロシア銀行との特派員関係のセキュリティ問題のみを検討します。 それでも、得られた結果を使用して、安全性やその他のタイプの計算を保証できます。

非現金支払いのIBシステムの必須要件

主な脅威を検討する際に、それらの損害を評価しましたが、それらの実装の可能性は評価しませんでした。 事実、考えられる最大の被害がどの銀行でも同じである場合、脅威の確率は銀行ごとに異なり、適用される保護対策に依存します。

情報セキュリティの脅威の実装の可能性を減らすための主な手段の1つは次のとおりです。

• ITおよびインフラストラクチャ管理のベストプラクティスの実装。
• 統合情報セキュリティシステムの作成。

ここではITプラクティスについては説明しません。情報セキュリティの確保の問題についてのみ触れます。

情報セキュリティを確保する際に考慮する必要がある主なニュアンスは、この種の活動が州と中央銀行によってかなり厳密に規制されていることです。 リスクがどのように評価されても、銀行が利用できるリソースがどれほど小さくても、銀行の保護は確立された要件を満たさなければなりません。 そうしないと、機能しません。

ロシア銀行との特派員関係のビジネスプロセスに課せられる情報の保護を組織するための要件を検討してください。

表3

要件ドキュメント	従わなかった場合の罰
個人データ保護。 理由-支払文書には個人データがあります（支払人/受取人の氏名、住所、身分証明書の詳細）
2006年7月27日付「個人データに関する」連邦法No. 152-FZ	ロシア連邦 行政法 第13.11条 、ロシア連邦法第13.12条の行政法 -最大75千ルーブル。 結構。 刑法第137条 -懲役2年まで
2012年11月1日のロシア連邦政府の政令第1119号「個人データ情報システムでの処理中の個人データ保護の要件の承認について」
2013年2月18日付けロシアFSTECの命令第21号「個人データが個人データ情報システムで処理される際の個人データのセキュリティを確保するための組織的および技術的措置の構成および内容の承認について」（2013年5月14日、ロシアの法務省N 28375に登録）
2014年7月10日付ロシア連邦警備局の命令第378号セキュリティレベルごとのデータ」（2014年8月18日、ロシアの法務省N 33620に登録）
ロシア銀行条例第3889-U、2015年12月10日付、「個人データ情報システムでの個人データの処理における実際の個人データのセキュリティに対する脅威の特定について」
国内支払いシステムでの情報保護の確保。 ベーシス-送金を行う信用機関は、国の支払いシステムの一部です。
2011年6月27日付けの「国内支払いシステムに関する連邦法」第161-FZ号	第6条、記事 1990年2月12日付けの連邦法20号No. 395-1「銀行および銀行業務について」-ライセンスの取り消し
2012年6月13日のロシア連邦政府令第584号「支払いシステムの情報保護に関する規制の承認について」
2012年6月9日のロシア銀行規則No. 382-P「送金時の情報保護を確保するための要件、およびロシア銀行が送金時の情報保護を確保するための要件の遵守を監視する手順について」
2016年8月24日のロシア銀行規則No. 552-P「ロシア銀行決済システムにおける情報保護の要件について」
SKZI SKAD署名の運用ドキュメント
ロシア連邦の重要な情報インフラストラクチャを保護します。 グラウンド- 条項8の条項による銀行 2 2017年7月26日のFZ No.187-FZは重要な情報インフラストラクチャの主題です
2017年7月26日の連邦法第187-「ロシア連邦の重要な情報インフラストラクチャの安全性について」	刑法第274.1条 -懲役8年まで
2018年2月8日N 127のロシア連邦政府の決議 「ロシア連邦の重要な情報インフラストラクチャのオブジェクトを分類する規則の承認、およびロシア連邦の重要な情報インフラストラクチャのオブジェクトの重要性の基準の指標のリストとその価値」
2017年12月21日付けロシアFSTECの命令第235号「ロシア連邦の重要な重要インフラのセキュリティシステムの作成要件の承認とその機能の確保について」（2018年2月22日ロシア法務省登録第50118号）
ロシアのFSTECの命令2017年6月12日N 227「ロシア連邦の重要な情報インフラストラクチャの重要なオブジェクトの登録を維持するための手順の承認について」（2018年2月8日、ロシア法務省に登録N 49966）
2017年12月22日のロシア連邦大統領令N 620「ロシア連邦の情報資源に対するコンピューター攻撃の結果を検出、防止、排除するための国家システムの改善について」
ロシア銀行の決済システム内で資金を転送する際に、電子メッセージング契約によって確立された情報保護要件。 理由-この契約は、ロシア銀行との支払い文書の電子交換のためにすべての信用機関によって締結されています。
ESをアプリケーションと交換するための一般的な契約。 AWSのCBD、UTAのドキュメント（それらの使用の要件は、パラグラフ1に反映されます。契約の付録3）	契約の9.5.4条項 -ロシア銀行の主導による契約の一方的な終了。

また、情報セキュリティの組織に対する追加要件も示しています。 これらの要件は一部の銀行にのみ適用され、場合によってのみ適用されます。

1. STO BR IBBS 標準および付属文書のセットは、信用機関によって自発的に受け入れられた場合にのみ有効です。
2. PCI DSS 標準は、完全な非マスク支払いカード番号（PAN）が支払い文書で送信される場合にのみ有効です。
3. 企業情報セキュリティポリシー。 要件は、グループのすべての銀行に対して統一されたISポリシーが確立され、各銀行がそれに基づいて内部ドキュメントを作成する必要がある大規模な銀行グループに関連しています。

これらすべての要件の適用の最終結果は、リストされたドキュメントのいずれかを満たす情報セキュリティシステムでなければなりません。 そのようなシステムを作成するために、要件は単一の表にまとめられ、いくつかの同様の要件がある場合、最も厳しいものが選択されます。

ここには重要なニュアンスがあります。規制文書で指定された要件には、通常、厳しい仕様が含まれていません。 セキュリティシステムがどのように見えるべきか、何から構成されるべきか、どのような戦術的特徴を持つべきかを示します。 例外は、SKZI SKAD署名など、使用されている情報保護ツールの運用ドキュメントに基づく要件です。

たとえば、 FSTEC No. 21の要件の断片を考えてみましょう

表4


ご覧のとおり、 AVZ.1およびAVZ.2の要件は、アンチウイルス保護が必要であることを示しています。 これらの要件は、ネットワークノード上での具体的な構成方法を規制するものではありません（2014 年3月24日付けのロシア銀行レター49-Tは、銀行がAWP、サーバー、およびゲートウェイにさまざまなメーカーのウイルス対策をインストールすることを推奨しています）。

状況は、コンピューターネットワークのセグメント化（ VMS.17の要件）と同様です。 この文書は、保護のためにこのプラクティスを使用する必要性のみを規定していますが、組織がどのようにそれを行うべきかについては述べていません。

情報保護ツールを具体的に構成し、保護メカニズムを実装する方法は、情報セキュリティの脅威をモデル化した結果に基づく情報保護システムのプライベートな技術タスクから学習します。

したがって、統合された情報セキュリティシステムは、必須要件、現在の脅威、および情報セキュリティを確保する慣行の履行を考慮して構築された一連の保護ビジネスプロセス（英語の文献ではコントロール）である必要があります。