1 / 46

セキュリティポリシー: 米政府/米国防総省の取り組み

セキュリティポリシー: 米政府/米国防総省の取り組み. Lance Spitzner. 自己紹介. セキュリティコンサルティングおよび研究における8年間の経験を持つ。脅威に関する情報収集を重点的に取り組む。 「 Honeypot: Tracking Hackers 」 の著者、「 Know Your Enemy 」 の共同著者、および数々のセキュリティ関連文を出版 7 年間の米軍勤務、うち4年間は緊急派遣軍( RDF) 将校として勤務. セキュリティポリシーの重要性. 情報セキュリティにおける、第一の、また最も重要なステップの一つである

cyndi
Download Presentation

セキュリティポリシー: 米政府/米国防総省の取り組み

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. セキュリティポリシー:米政府/米国防総省の取り組みセキュリティポリシー:米政府/米国防総省の取り組み Lance Spitzner

  2. 自己紹介 • セキュリティコンサルティングおよび研究における8年間の経験を持つ。脅威に関する情報収集を重点的に取り組む。 • 「Honeypot: Tracking Hackers」の著者、「Know Your Enemy 」の共同著者、および数々のセキュリティ関連文を出版 • 7年間の米軍勤務、うち4年間は緊急派遣軍(RDF)将校として勤務

  3. セキュリティポリシーの重要性 • 情報セキュリティにおける、第一の、また最も重要なステップの一つである • 自身の経験から言えば、セキュリティポリシーは、残念ながら最も後回しにされるステップである(ポリシーの作成が実行されるとした場合)

  4. なぜ米政府/米国防総省のポリシーが注目されるのか?なぜ米政府/米国防総省のポリシーが注目されるのか? • 実際のポリシーの例を入手するのは非常に困難(しばしば機密とみなされる) • 米政府/米国防総省は、構造化したアプローチ法を、公開、発表している • 真剣に取り組んでいる(失うものは大きい) • ポリシーを適切に開発するために投資する資源を有し、投資回収率を証明する必要はない

  5. 定義 セキュリティポリシーは、組織がセキュリティ目標に到達するために、どのように情報およびIT資源を管理、保護するかを規制する基準を定義する(CERT:米コンピュータ緊急対応チーム)

  6. 具体的には? • 一連の文書資料 • 文書資料は最新のものに保つために頻繁に更新される「生きた文書」である • 基本的には、企業の重要な財産が何か、その財産をどのように保護しなければならないのか(もしくはできるか)の概要を説明した計画のこと

  7. 課題 • ポリシーは開発が非常に難しく、それぞれの組織独自のものであることが多い • ポリシー策定に関する一般的な形式およびプロセスはない • すべての人が理解し活用できるように、単純化することが必要 • 経営側の合意を得る • ポリシーの施行方法を定める

  8. 米政府/米国防総省 • 一つの組織が包括的な責任を有するのではなく、それぞれの組織において、ポリシーを策定、実施する • 米政府のガイドラインはOMB(行政管理予算局)が、国防総省のガイドラインは国防総省が定める • NIST(米国立標準技術研究所 )やCERT(コンピュータ緊急対応チーム)のような機関が、助力となる白書やテンプレートを提供している

  9. 行政管理予算局 OMB 回報 A-130、Appendix III は、以下のことを義務付けている   システムの使用、システムにおけるセキュリティ、およびシステムの許容できる危険レベルに関する行動の一連の規定を定める。規定はシステムの様々なユーザのニーズに基づくものとする。この規定により要求されるセキュリティは、システムの情報に十分なセキュリティを提供するために必要なだけ厳格なものとする。このような規定はシステムの情報にアクセス可能な個人すべての責任と予想されうる行動をはっきりと描写するものにすること。また、これらの規定は他のシステムへの相互接続の適切な制限を含み、サービス提供や復旧における優先順位を定義する必要がある。最後に、これら規定に従わない際の措置についても、明確化する必要がある。

  10. FISMA • Federal Information Security Management Act (連邦情報セキュリティ管理法)の略 • 連邦政府が情報セキュリティを強化するために役立つ、フレームワークと最低限の管理策を提供する • 2002年に下院通過。 OMBは、FISMA施行を強化および監督する権利を憲章によって定められている

  11. 米国防総省ポリシー • 国防総省全体のポリシーは、国防総省のジョイントスタッフ/J6 およびネットワーク・情報インテグレーション担当国防次官補室が共同で策定 • 各部局は、自身のアプリケーションおよび状況に合わせて独自のポリシーを定めることができ、またそうしている(例:軍艦によって異なる機器構成の一つ一つすべてを、国防総省のポリシーで対応するには限界がある) • DISA(国防情報システム局)は、ネットワークの接続性を保証するために、 Secure Technical Implementation Guides (STIGs)と呼ばれる、セキュリティ設定ポリシーを定めている(任意で使用可能)

  12. 一般的なポリシーの例 • ネットワークに追加を許可するシステム、およびその際に厳守しなければならない規準や手順 • 監視対象、および監視条件や方法(例:警告バナー) • 情報の分類基準、および取り扱い方法 • インシデントに関する説明および報告方法 • ポリシーの施行方法 • AUP(従業員の一番大きな問題である場合が多い) AUP(利用規定):ネットワークを利用する際の利用目的を制限する規則

  13. 基本的なアプローチ • 保護対象を特定する • 何に対して保護するのかを明確にする • 情報資産に及ぶ可能性のある危険を定義する • ポリシーの施行方法を定める(施行可能なものでなければならない)

  14. 訓練と意識付け • ポリシーが承認され、組織全体に普及したら: • 全従業員を訓練、教育する • 全員に署名させる • 直ちにポリシーの施行を開始する • 人事関連以外の活動を達成する • セキュリティ担当者は、実現可能性を常に評価する

  15. OMB要件 • システムへのアクセスを許可する前に、セキュリティ責任について、全員が適切な訓練を受けていることを確実にすること。 • 訓練によって、従業員がシステムの規定を熟知できるようにすること。また、訓練は、NISTやOPMが発行するガイダンスとの整合性が取れていると同時に、利用可能な支援策およびセキュリティ製品や技術について、従業員に通知するものであること。 • 引き続きシステムにアクセスするために、従業員は、システムの規定に従った行動をとり、周期的な再訓練を受けること。

  16. 施行 • 常にすべての違反者を捕らえることはできない • セキュリティ侵害の防止に十分とされる範囲で、違反者を捕らえる

  17. 改訂 ポリシーは「生きた文書」であり、組織の変更に応じて改訂されなければ、そのポリシーは組織にとって全く役に立たないものとなる、ということを念頭に置く必要がある。

  18. 要点 • ポリシーはできるだけシンプルに保つ • ポリシー策定にスタッフを含める • セキュリティ意識向上とトレーニング • 必ず全従業員がポリシーを通読、理解、および承認の署名をするようにする • 明確な処分を定め、実施する

  19. セキュリティモジュール 防止 検知 対応 改善

  20. 防止 • 脅威を回避する(内部/外部脅威)

  21. 防止のためのポリシー • 最小化された、安全な体系のための標準を明文化する • ネットワークにIPスタックもしくは新しいアプリケーションなどを追加する承認プロセス • 利用規定(AUP) • システムとアプリケーションを最新のものに保つ

  22. システムアクセス 以下の通知と合意バナーは、米国防総省の総務会で承認され、セキュリティおよびアクセス制御を実施しているすべての国防総省Webサイトで使用可能。 各機関は、事前に総務会から承認された場合のみ、バナーを編集して使用することができる。 「これは国防総省コンピュータシステムである。関連する機器、ネットワークおよびネットワークデバイス(特にインターネットアクセス)を含む当コンピュータシステムは認可された米政府が使用するために供給されている。 国防総省コンピュータシステムは、その使用が許可されているものであることを保証するため、システム管理を実施するため、非認可アクセスからの保護を容易にするため、およびセキュリティ手順、生存性、運用セキュリティを確認するためなど、合法な目的で監視される場合がある。当システムのセキュリティを立証するため、モニタリングには、認可された国防総省のエンティティによる能動的な攻撃が含まれる。モニタリングの間、情報は認可された目的のために、調査、記録、および複製される。当システム上の情報、およびシステム上で送受信される情報は、個人的な情報も含め、全て監視の対象となる場合がある。 認可、非認可を問わず、当国防総省コンピュータシステムを利用した場合、当システムのモニタリングに合意したものと見做す。非認可での使用は、刑事訴追の対象となる可能性がある。モニタリング中に収集された非認可使用に関する証拠は、刑事的、管理的、もしくは他の措置をとる目的で使用される可能性がある。当システムを使用した場合、これらの目的に基づいたシステムの監視に同意したものと見做す。」

  23. 脅威レベルを特定する • 脅威1: 故意でない、もしくは不測の事態。 例)電源コードにつまづくなど • 脅威2: 受動的、偶然の最小資源を用いる敵、危険を冒すつもりがほとんどない。 例)リスニングなど • 脅威3: 最小資源を用いる敵、大きな危険を冒す意図がある。例)技術のないハッカーなど • 脅威4: 適度な資源を用い、高度な技術を有する敵、危険を冒すつもりがほとんどない。 例)組織犯罪、高度な技術を有するハッカー、国際企業など • 脅威5: 適度な資源を用い、高度な技術を有する敵、大きな危険を冒す意図がある。例)国際的なテロリストなど • 脅威6: 豊富な資源を用い、非常に高度な技術を有する敵、危険を冒すつもりがほとんどない。 例)資金力のある国営研究室、民族国家、国際組織など • 脅威7: 豊富な資源を用い、非常に高度な技術を有する敵、大きな危険を冒す意図がある。 例)危機におかれた民族国家など

  24. 国防総省パスワードポリシー 国防総省のポリシーはすべてのパスワードを以下の要件に従って設定することを定めている: • 長さは、最低8文字、可能であれば12-16文字 • 大文字と小文字、数字と特殊文字の組み合わせ • 90日ごと、もしくは指示により変更する • 個人のパスワードの使用履歴は、古いパスワードの再使用を防止するために、1年間残される • 辞書に掲載されているいかなる単語も使用しない • パスワードはいかなる端末機、もしくはプリンタにも表示してはならない • ユーザは、システムにログオンする際、パスワードの開示を防ぐため適切な行動をとる

  25. 国防総省リムーバブルメディアポリシー • 国防総省のシステムに取り込むすべてのメディアは、アプリケーションやファイルを実行するのに先立ってウイルススキャンをするものとする • ドライブとCDバナーは、実行可能な限り無効にする • ファイルをリムーバブルメディアに転送する場合、適切な分類マークを使用して適切にラベル付けを行う(前もって印刷されたIDを使用するか、もしくは手書きで)

  26. モバイルコードポリシー • 電子メールのモバイルコード。電子メールによって、ユーザのワークステーションに悪質なモバイルコード(ウイルスやワーム)がダウンロードされる重大なリスクを考慮し、電子メールのモバイルコードに関する国防総省ポリシーはより厳しいものになっている。可能な限り、電子メールの本文や添付物に含まれるすべての種類のモバイルコードを自動実行する機能を無効にする。また、可能な場合は、モバイルコードを含む可能性のある電子メールの添付物を開く前に、常にユーザにメッセージを表示するようにデスクトップソフトウェアを設定する。 • 電子メールの本文および添付物に含まれるすべてのモバイルコード(例:ActiveX, Java, JavaScript, and VBScript)の自動実行を無効にする。 • 電子メールの本文および添付物に含まれるHTMLファイルの自動実行を無効にする(可能なときは) • モバイルコードを含む可能性のある電子メールの添付物を開くのに先立って、ユーザにメッセージを表示する。 • 電子メール製品が、Windowsスクリプティングホスト(WSH)に、添付物に含まれたモバイルコードを自動転送し、コードが実行されるのを防ぐ。 • 電子メール製品のなかには、これらの対策を実施するよう設定できないものもある。しかし、システム管理者は、この中からできる限り多くの対策を実施できるようにする。

  27. 国防総省システムバックアップポリシー • システムバックアップはすべての国防総省システムにおいて、少なくても一週間に一度実施すること • 脅威レベルが上がる場合、システムのミッションクリティカル性の度合いに基づいてバックアップの頻度をあげること • バックアップされたデータのそれぞれに対し、完全性チェックを行うこと

  28. 国防総省電子メール/インスタントメッセージング国防総省電子メール/インスタントメッセージング • 認可された、非機密政府事業はUSG電子メールアカウントを使用する • 契約人および外国人は国防総省ユーザ 電子メールアドレス(john.smith.ctr@army.mil またはjohn.smith.uk@army.mil)および電子署名(例:John Smith, Contractor, J-6K, Joint Staff)で特定される。契約人が電子メールアドレスに使用する略語は「ctr.」とする。外国人、もしくは国別コードの使用については、付加的なガイダンスが提供されている。 • AOL(IMを含む), HOTMAIL, ICQ, MSN Messenger もしくはYAHOOのような未承認アカウントは、DAAによって特別に使用が許可されている場合を除き、公式な事業には使用しない。ISPもしくはWebベースの電子メールおよびIMシステムは、任務を遂行するのに必要かつUSG所有の電子メールシステムが利用できない場合にのみ、使用が許可される。 • 匿名のメール出力先変更のために使用されたメールサーバからの、もしくはメールサーバへのメール接続は、すべて遮断される。メールは個人へ、および既知のサーバへ追跡可能でなければならない。

  29. 国防総省Webサーバセキュリティ   外部からアクセスできる国防総省Webサーバは、それを提供している団体の内部ネットワークから隔離されているべきである。隔離は物理的、もしくは承認されたファイアウォールのような技術的手段で行う。サーバソフトウェアはFIPS 140-2とし、すべてのセキュリティパッチが正しくインストールされている必要がある。承認された国防総省セキュリティプロトコルはすべてのWebサーバで使用する。付加的なセキュリティ手段はそれぞれの国防総省Webサイトのリスク管理アプローチおよびセキュリティポリシーに基づいて採用される。考慮される付加的な手段の例は: • IP転送を無効にする、デュアルホームサーバを避ける • 「最小特権」を採用する • Webサーバ実行の機能を制限する • ホストの設定を確認するツールを採用する • イベントログを有効にし、定期的に調査する

  30. リスクレベルの管理 脆弱性の様々なリスク重要度を管理するため、DISAは異なった3つのタイプの脆弱性警告を設定している • Information Assurance Vulnerability Alerts(IAVA:情報保障脆弱性警告): • 重大な脆弱性 • 国防総省の情報インフラに対する直接的な脅威 • 遵守行為が必要 • Information Assurance Vulnerability Bulletin(情報保障脆弱性報告) • 危険度が中度の脆弱性 • 脅威が深刻化する可能性 • 認知が必要 • Technical Advisory(技術勧告) • 危険度が低い脆弱性 • 脅威が深刻化する可能性は低い

  31. IAVAプロセス • Information Assurance Vulnerability Alert プロセスは「積極的な制御」を特徴とする勧告システムである。以下の特徴を含む: • それぞれのネットワークには、責任者として、特定のセキュリティ/システム管理者が、名指しで割り当てられている • それぞれの勧告通知は上記の責任者に送られる • (しかるべき重要性があると見做された)それぞれの通知は、通知の受取人に対する強制的確認応答要求を含む。 • 修正措置を要求するそれぞれの通知は、実行日付を明記している • DISAは修正が行われたかをリモートから自動で確認する方法を開発する • IAVAプロセス実施は以下の要素を含む: • OSおよびアプリケーションにおけるセキュリティ関連の欠陥を特定する • 国防情報基盤(DII)に及ぼす影響の深刻さに基づいて脆弱性を評価する • 最高司令官(CINC)、軍、および政府機関への脆弱性通知を広め、指揮官の関与を促す • CINC、軍、および政府機関が、通知の受領と推薦される修正措置へのコンプライアンス(遵守)を自動で報告する手段を提供する • コンプライアンスの統計は国防総省上位指導部への報告のため追跡される

  32. 検知 • 遅かれ早かれ、防止策が失敗することはある • その失敗はできるだけ早く検知されるべき

  33. ポリシーに関する問題 • どんな情報が収集され、監視されるか? • どのように情報が収集されるか? • どこに情報を集めるか? • だれに情報へのアクセス権を与えるか? • その情報はどのように、またいつ確認されるか? • 何がインシデントを決定づけるか? • どんな優先順位が関係しているか?

  34. 契約組織 • 多くの米軍および政府機関は、営利組織にセキュリティ問題の検知を委託している

  35. 空軍のポリシー 契約組織は、侵入検知ツールを使用して、24時間/年中無休の体制で侵入検知を目的とした監視を行い、管理下にあるシステムサーバ、ソフトウェア、データベース、ネットワーク、ファイアウォールのシステム監査ログを提供する 。侵入検知に関する報告は、毎日、監査、修正措置のためにISSMに提出される。続いて契約組織は、ISSMの要請を受け、システム脆弱性を取り除く、または将来の侵入攻撃を防ぐために、迅速な修正措置をとる。

  36. 米陸軍 ネットワークモニタリングポリシー • 対敵諜報活動(Counterintelligence)および法執行機関(Law Enforcement)職員だけが、適切な法的権限を得たのち、個人のコミュニケーションの内容を傍受することが許可される。 • ユーザの電子メールを閲覧したり、読んだりすることは禁止されている。システム管理者/ネットワーク管理者は、関係する団体からインシデント調査に関する特定の合意を得ている、 LE/CIの適切に認可された調査の一部である、あるいは調査ではない管理サーチの必要な要素である場合、電子メールメッセージを傍受、取り込み、もしくは回復することができる。全面的合意や警告バナーは、管理者に以上のような合意を与えるものではない。 • システム管理者/ネットワーク管理者はISのオペレーションを妨げる電子メールメッセージまたはファイルを作成者、受取人の合意なしに削除する場合がある。システム管理者/ネットワーク管理者は作成者もしくは受取人にそのような行為に関して通知する。

  37. 対応 問題が検知された場合は、できるだけ迅速にその問題の緩和に取り組むべきである

  38. 対応ポリシー • インシデントとは何か、および優先順位のレベルを確認する • 何を達成したいのか? • バックアップ

  39. 米海軍 インシデント対応 • これらのシステムに関するインシデント、脆弱性、脅威および対策に関する情報を共有することにおいて、他の適切な機関との協力が求められる。 • 海軍および海兵隊のすべての指揮官、部隊、活動はどんなコンピュータ侵入インシデント、もしくは疑わしいものを、艦隊情報戦センター(FIWC/ FLTINFOWARCEN )に報告する。この報告は国防情報局(DIA)および国家安全保障局(NSA) /中央保安部(CCS)により特定の海軍および海兵隊指揮官に課された要求に加えられるものである。 • コンピュータネットワーク インシデントを経験した部隊による報告は、すべての利用可能な通信システムを介して送られる。

  40. 米陸軍 インシデントおよび侵入レポーティング米陸軍 インシデントおよび侵入レポーティング シリアス・インシデント・レポート(SIR)が作成され報告されるのは、以下の状況下においてである • インシデントによって、陸軍が、確立された情報オペレーションを行う能力に大きな危険が及ぶ。 • Webページ改変など、陸軍のイメージに悪影響をもたらす。 • 機密情報 (たとえば兵士ID情報(SSN) 、健康状態、患者クライアント間 および弁護士クライアント間の秘匿特権)へのアクセスもしくは変更。 • セキュリティ侵害の発信源が外国のソースである。 • 安全、生命、周囲を危険にさらす可能性がある、壊滅的な影響を与える可能性がある、もしくは陸軍に責任がある情報を含むシステムへの侵入

  41. エネルギー省(DOE) インシデントレポーティングエネルギー省(DOE) インシデントレポーティング • DOEの脅威を分析してDOEにガイダンスを与えることにおいて、コンピュータ事件対策機関 (CIAC) を援助するために、以下の情報が必要である: • 攻撃方法 • どのようにアクセスが取得されたか?どんな脆弱性が悪用されたか? • どのようにインシデントが検知されたか? • 攻撃者 • 責任ある団体の身元を特定する、通常はIP アドレスもしくはホスト名 • DOE Sensitive Country List(機密国家リスト)上の国が侵入に関係しているのか?

  42. エネルギー省インシデントレポーティング • 被害内容 • 侵入されたシステムはどんな種類の情報を処理していたか(機密か、もしくはOUO, UCNI, NNPI, エクスポート制御のような非機密か)? • システムはどんなサービスを提供していたか(DNS、キーアセットサーバ、ファイアウォール、VPN ゲートウェイ、IDSなど)? • 侵入者はどのレベルのアクセスを取得できたか? • どんなハッキングツールおよび技術が使用されたか? • 侵入者が削除、修正、または盗んだのは何か? • どんな非認可の情報収集プログラム(スニファなど)がインストールされたか? • 攻撃の影響はどれくらいか? • どんな防止、緩和措置が実行されて、進行しているか? • 攻撃時間 • いつサイバーセキュリティインシデントは検知されたか? • そのサイバーセキュリティインシデントは実際いつ起こったか?

  43. 改善 • セキュリティサイクルにおける最後のそして最終の過程である • 自分の事業とその脅威は常に変化している • 従って、常にセキュリティ対策を環境に応じて変更、強化すべきである

  44. 改善に関するポリシー • インシデントから学ぶ • 評価 • セキュリティトレーニングと意識向上 • 常に最新の状態に保つ • トレーニングコース • 書籍/刊行物 • メールリスト

  45. NIST 評価ドキュメント • NIST Special publication 800-26 • セキュリティSelf-assesment(自己評価)ガイド • Self-assesment(自己評価)は機関の担当者が現在の情報セキュリティプログラムの状況を判断し、必要なら改善のための対象を定める手段を提供する

  46. 米国防総省/米政府ポリシー URL http://www.radium.ncsc.mil/tpep/library/rainbow/ http://docs.usapa.belvoir.army.mil/jw2/xmldemo/r25_2/main.asp http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf http://sc.afit.edu/support/policy_security/policy/app_mail.html http://www.cpms.osd.mil/vmo/documents/SOW/Files/A16%20Intrusion%20Detection.wdf.doc http://www.dodig.osd.mil/audit/reports/fy01/01184sum.htm http://www.hpcmo.hpc.mil/Htdocs/DREN/dren-up.html http://nileweb.gsfc.nasa.gov/security/access-policy1.html http://www.usna.edu/InfoTech/Policies/Policies_AcceptableUse.htm

More Related