web-dev-qa-db-ja.com

銀行会社のパスワードポリシーを作成する場合、何を考慮する必要がありますか？

パスワードポリシーなどのセキュリティポリシーを作成する場合、保護する必要のある一般的な資産にはどのようなものがありますか？

そして、これが、組織が提供する、または組織がサポートするアプリケーション、プログラム、ネットワーク、システム、およびデバイスにアクセスする従業員、請負業者、ベンダー、サプライヤー、および代表者にどのような影響を与えますか。

大規模なスタッフ、さまざまなデータセンター、イントラネット、およびWebベースのアクセスを持つ銀行会社。

情報：

  • 顧客に関するデータ。
  • 支払い取引。
  • 従業員に関する情報。
  • ログ。

保護する必要がある、他のどの資産または情報を含めることができるか。さらに、スタッフが自分の口座を持っている銀行の顧客に関する機密情報にアクセスできるように、何らかのタイプのパスワードポリシーを設計する必要があります。従業員が利用する銀行のデジタル環境。

  • 管理者
  • 最高経営責任者（CEO
  • 従業員
  • お客さま
passwordspassword-managementpassword-policypassword-reset
3
John Smith

パスワードポリシー

パスワードポリシーは、孤立して作成することはできません。組織のセキュリティポリシーとプロセスから取得する必要があります。通常、これはISMSまたは情報セキュリティ管理システムと呼ばれます。一般的なケースでは、情報セキュリティのさまざまな側面に対応するさまざまなポリシードキュメントで構成されます。

バンキングおよびペイメントの場合、ISMSはビジネスユニットに、少なくとも以下の標準および規制の成果物からベストプラクティスを導出するよう指示します。

  • PCI SSC – Payment Card Industry Security Standards Council
  • SOX – Sarbanes-Oxley Act
  • GLBA –グラムリーチブライリー法
  • …そして潜在的に他のもの。

PCI、SOX、およびGLBAの要件に従って、パスワードのニーズは次の要件に準拠します。

PCI DSS

  • 2.1 –ベンダー提供のデフォルトを使用しない
  • 2.3 –強力な暗号化を使用して、コンソール以外のすべての管理アクセスを暗号化する
  • 3.6.6 –手動の平文暗号鍵管理操作を使用する場合、これらの操作は知識分割と二重制御を使用して管理する必要があります。
  • 6.3.1 –アプリケーションがアクティブになるか顧客にリリースされる前に、開発、テスト、および/またはカスタムアプリケーションアカウント、ユーザーID、およびパスワードを削除します。
  • 要件8：システムコンポーネントへのアクセスを識別および認証するを参照してください

[〜＃〜] sox [〜＃〜]

Sarbanes-Oxleyの専門家と監査人は、コンプライアンスの最小要件を満たすために、パスワードは次のようにすることを推奨しています。

  • 長さが8文字以上であること。
  • 文字と数字の組み合わせを含めます。
  • 個人情報は含まれません。

[〜＃〜] glba [〜＃〜]

GLBAのセクション501「非公開の個人情報の保護」では、金融機関が、顧客の記録と情報の管理上、技術上、および物理的な保護に関する適切な基準を確立する必要があります。これらのセーフガードの範囲は、金融機関が次のことを義務付けているGLBAデータ保護規則で定義されています。

  • 顧客データのセキュリティと機密性を確保する
  • そのようなデータのセキュリティまたは整合性に対する合理的に予想される脅威または危険から保護する
  • 顧客に重大な危害または不便をもたらすようなデータへの不正アクセスまたはデータの使用から保護します。

セキュリティポリシー

あらゆる種類のセキュリティポリシーを作成する場合、インフラストラクチャ、アプリケーション、オペレーティングシステムで構成される情報システムなどの資産を最初に検討する誘惑を避けてください。代わりに、保護が必要な機密情報に焦点を当ててください。セキュリティポリシーは、セキュリティの要件と目的に対処する高レベルのステートメント（計画またはフレームワーク）です。組織全体に対応する場合もあれば、問題やシステムに固有の場合もあります。

セキュリティポリシーは、管理者が確立したセキュリティフレームワークを表すという点で、一種のガバナンスです。これは、組織がさまざまなトピックに期待を設定するための主要な方法です。

  • ポリシーの対象者は、組織が保護する必要のある情報の設計者、設計者、実装者、設置者、保守者、およびユーザーで構成されます。
  • ポリシーは、ハードウェア、ソフトウェア、アクセス、人、接続、ネットワーク、通信、施行などに影響を与えるように作成できます。
  • 達成すべきセキュリティ基準を包括的に理解しないと、優れたセキュリティポリシーを作成することはできません。

セキュリティ基準

セキュリティ標準は内部で開発される場合がありますが、通常、規制組織（PCI SSCなど）またはベストプラクティスの開発を担当する組織（NIST、ISO、ISACAなど）が作成した外部ドキュメントです。

  • セキュリティ標準は、ベストプラクティスを実装するために実行または実行する必要があるアクションまたはルールの列挙です。例：NIST SP-800-53、ISO 27001、COBIT

Process

  • セキュリティプロセスは、組み合わせたときに望ましい結果を生成する一連のアクティビティまたは関連タスクを定義します。

手順

  • 手順は、確立されたポリシー、プロセス、手順に従ってさまざまなタスクを実行するための段階的な指示です

ガイドライン

  • ガイドラインは、セキュリティポリシーまたはプロセスの目標を達成する方法に関するアドバイスを提供します。それらは提案を提供するために使用されるコミュニケーションツールであり、ルールを提供しません。

情報セキュリティポリシーの策定

データの識別とスコープ

  • 保護する必要がある機密情報を特定します。
  • 機密情報が記録されるすべての場所を特定します。
  • データ分類とタグデータを作成します。
  • 範囲内情報システムと範囲外情報システムを決定し、情報システムに適切にタグを付けます。
  • データにアクセスできる承認された方法を決定します。

リスク管理フレームワークを開発する

リスク管理フレームワークは、情報に関連するリスクとそれらのリスクを管理する方法を理解するのに役立ちます。

これは、パスワードポリシーを開発するための重要なプロセスです。

  • リスク評価フレームワークの確立
  • リスクを特定する
  • リスクを分析する
  • リスクを評価する
  • リスク管理オプションを選択する

リスク治療計画を作成します

これには、リスクを軽減および修正するためのセキュリティ管理策の作成と管理が含まれます。

まとめる

保護する必要のあるデータとそのデータを処理するシステム、最も一般的にさらされるリスクを理解したら、次に関連する情報システムの要件の開発を開始できます。

  • 規制要件;
  • データ分類;
  • ベストプラクティス;
  • ユーザー体験と受け入れ
1
W1T3H4T

この質問に答えてみましょう。

一般に、すべての資産の最新の在庫を持ち、重要な資産を決定し、セキュリティに関連するビジネスへの影響分析とアクション（機密性、整合性、アクセス可能性）に先立ってその重要性を優先することは、ビジネスオーナーの役割です。起こります。

組織のセキュリティに関連する資産とデータを次のように分類できます。

1）組織が所有し、以下を制御できる資産：

  • 物理的セキュリティ、物理的アクセス制御システム、電気、水、ガス、ファイバー、ケーブル、建物構造を含むメディアへのアクセス
  • オンプレミスITシステム、アプリケーション、ネットワークを含むオンプレミスインフラストラクチャ
  • IoTデバイス（ATM、ルーター、スイッチ、プリンター、ディスプレイ、PoSキオスク、スマートTVディスプレイ、UPS）
  • 企業のラップトップ、タブレット、スマートフォン
  • WiFiおよびLANネットワーク
  • VPNアクセス、
  • 仮想化（VM、仮想ファイアウォール、コンテナー）
  • モバイルバンキングアプリケーション（ソースコードへのアクセス、プラットフォームおよびショップへのアクセスを含む）
  • ファイアウォール
  • バックアップおよびアーカイブソリューション
  • パブリックおよびイントラネットのWebサイト
  • コンテンツ管理システム
  • 文書管理システム
  • プロセス自動化ソリューション
  • ビジネスインテリジェンス、ビジネスウェアハウスソリューション
  • 運用データデータベース
  • レガシーシステム、廃止されたシステム
  • 外部メディア上のデータ（USBスティック、メモリカード、外部ドライブ、CD/DVDストレージ）
  • メールを含む機密印刷物
  • スマートカード、ハードウェアセキュリティトークン
  • 生体認証データリポジトリ
  • ソフトウェア開発ライフサイクル関連（CI/CDアプリケーション、ソースコードのバージョン管理リポジトリ、開発アクセスキー）
  • テスト環境
  • 実験的/サンドボックスシステム
  • データ漏洩防止システム
  • ロギングおよび監査システム
  • アイデンティティおよびアクセス管理システム
  • ガバナンス、リスク、コントロールシステム
  • 不正管理システム
  • コールセンターシステム
  • CRMシステム
  • PIIデータ：従業員データ、顧客データ、ベンダーデータ（マスターデータ、音声/音声録音）
  • IP：知的財産、戦略分析、契約、および調達
  • ソフトウェアライセンス、
  • ソフトウェアパッチ、
  • パスワード管理ソフトウェア

2）組織が相互作用するが以下に対する制御が制限されているアイテム：

  • 従業員、外観、オンサイト請負業者、
  • クラウドシステム（IaaS、PaaS、SaaS、FaaS）、
  • サードパーティシステムとそのメンテナンスおよびセキュリティロードマップ
  • サードパーティのソフトウェアとそのメンテナンスおよびセキュリティロードマップ
  • BIOS
  • OSソースコード
  • 顧客、ベンダー、政府向けのインターフェース/ミドルウェア/ APIアクセス、
  • お持ちのデバイス（スマートフォン、タブレット、ノートパソコン）
  • ベンダーとそのITシステム
  • サードパーティのロードバランサー、キャッシュ
  • サードパーティのOATH、識別および認証プロバイダー

3）組織が制御できない項目：

  • コネクタ/ API /定期的なデータ転送を介してデータを要求および収集する顧客とそのITシステム、政府（規制、コンプライアンス、法的、法執行機関）システム、
  • 自動インターネットクローラー、データコレクター、ボット
  • ランダムな訪問者
  • ハードウェアレベルのセキュリティ（CPU、メモリ、トラステッドプラットフォームモジュール、データポート）
1
Refineo