• 検索結果がありません。

目次 はじめに... 2 本書の対象読者 昨今の脅威の実情 脅威の全貌 攻撃者が期待する段階ごとの脆弱性 設計 運用上の弱点 設計上 運用上の弱点を生む 10 の落とし穴 メールチェック

N/A
N/A
Protected

Academic year: 2021

シェア "目次 はじめに... 2 本書の対象読者 昨今の脅威の実情 脅威の全貌 攻撃者が期待する段階ごとの脆弱性 設計 運用上の弱点 設計上 運用上の弱点を生む 10 の落とし穴 メールチェック"

Copied!
25
0
0

読み込み中.... (全文を見る)

全文

(1)

攻撃者に狙われる設計・運用上の弱点についてのレポート

(2)

1

目次

はじめに ... 2 本書の対象読者 ... 2 1. 昨今の脅威の実情 ... 3 1.1. 脅威の全貌 ... 3 1.2. 攻撃者が期待する段階ごとの脆弱性 ... 4 1.3. 設計・運用上の弱点 ... 9 2. 設計上・運用上の弱点を生む 10 の落とし穴 ... 10 2.1. メールチェックとサーバ等の運用管理用の端末が同一 ... 11 2.2. 分離できていないネットワーク ... 12 2.3. 止められないファイル共有サービス ... 13 2.4. 初期キッティングで配布される共通のローカル Administrator ... 14 2.5. 使いこなせない Windows セキュリティログ ... 15 2.6. パッチ配布のための Domain Admin ... 16 2.7. ファイアウォールのフィルタリングルール形骸化 ... 17 2.8. 不足している認証プロキシの活用とログ分析 ... 18 2.9. なんでも通す CONNECT メソッド ... 19 2.10. 放置される長期間の http セッション ... 20 3. 脅威の全貌をふまえた対策の考え方 ... 21 3.1. 対策の全体像 ... 21 3.2. 攻撃シナリオと対応機器の関係 ... 22 おわりに ... 23

(3)

2

はじめに

近年、インターネットを介して組織の機密情報を盗み取る、諜報・スパイ型の標的型攻撃(以下、 標的型攻撃)が相次いでいる。今日では、政府機関から民間企業に至るまで幅広く狙われており、 国益や企業経営を揺るがす懸念事項となっている。 他のサイバー攻撃と異なり、標的型攻撃の特徴は、複数の攻撃を組合せた一連の攻撃シナリオに よって組立てられている。攻撃者は標的とする組織の情報を盗むために、マルウェアやソフトウェ アの脆弱性悪用、ハッキングなどの複数の手法を戦術的に組合せて、システム攻略を試みる。その ため、防御側も特定の対策を一辺倒に行うのではなく、一連の攻撃シナリオに沿って、複数の対策 を組合せることによって、連鎖的な攻撃を断切る必要がある。 標的型攻撃の対策といえば、入口対策やエンドポイント対策等に視点が集中しがちである。いず れも適切な標的型攻撃への対策であるが、正確に言うと「標的型攻撃の一部」への対策である。残 念ながら、標的型攻撃を完璧に食い止める魔法の杖は存在せず、入口対策やエンドポイント対策は、 システム内部に侵入された後の攻撃行為に対しては、対策として無力である。 一方で、システム攻略に際しての防御側の脆弱性(広義の意味での脆弱性)を、脅威の全体像に 照らし合わせると、攻撃者に狙われる脆弱性は、ソフトウェアだけではなく、システム設計・運用 上の弱点が悪用されている。通常、業務システムは、業務を効率化するためのに活用されるもので、 セキュリティの強化とはトレードオフの関係にあることが多い。そのため、どうしても設計・運用 上の弱点が発生してしまう。 このような背景を踏まえ、本書では2013 年 8 月にIPAより公開した「『標的型メール攻撃』対策 に向けたシステム設計ガイド1」を補完する形で、脅威の全体像とその意外な設計・運用上の弱点 を指摘しており、現実を踏まえた実効的なセキュリティ対策に向けた情報提供を行う。 本書が安全なシステム設計の検討に活用されることを期待している。

本書の対象読者

・システムの運用管理者 ・システムの設計者 ・システムのセキュリティ担当者 ・システム発注者/企画者 1 「『標的型メール攻撃』対策に向けたシステム設計ガイド」http://www.ipa.go.jp/security/vuln/newattack.html

(4)

3

1. 昨今の脅威の実情

1.1. 脅威の全貌

標的型攻撃は、いくつかの手法を組み合わせ、明確な攻撃意図と確実に攻略に至るための戦術的 な攻撃シナリオに沿って、遂行される。また、攻撃シナリオは、メールやウェブ経由でシステム内 部に侵入した後、段階的にシステムの攻略範囲を拡大していき、情報の窃取・破壊等の目的遂行に 至る。 図 1.1.-1 脅威の全貌イメージ 例えば、2013 年に多くの被害を出したウェブサイトの改ざん2は、ウェブサイトだけの問題とし て捉えがちであるが、標的型攻撃の全貌から見ると、システム侵入のための一手段である。正規の ウェブサイトをマルウェア感染を引き起こす罠サイトに改ざん(水飲み場を構築)し、ウェブサイ トにアクセスしたユーザをマルウェアに感染させ、システム侵入の足がかりとする。 システム内部の端末が一度感染すると、バックドアが仕掛けられ、遠隔操作されるようになる。 その後、内部へ侵入を拡大するための情報収集とツールがダウンロードされ、少しずつ侵入基盤が 確立していく。 このように、マルウェア感染がシステム侵害活動の入口となり、内部に対する潜伏活動、情報窃 取活動につながり、組織・企業にとって大きな脅威となっているのであるが、この時に狙われて悪 用されるもう一つの脆弱性が、「設計・運用上の弱点」である。 2 2013 年 6 月 26 日付の注意喚起 http://www.ipa.go.jp/security/topics/alert20130626.html 2013 年 9 月 6 日付の注意喚起 http://www.ipa.go.jp/security/topics/alert20130906.html

(5)

4

1.2. 攻撃者が期待する段階ごとの脆弱性

標的型攻撃から組織・企業の情報資産を守るためには、攻撃シナリオにおける各段階の攻撃手口 と狙われる脆弱性を理解する必要がある。以下に「『標的型メール攻撃』対策に向けたシステム設 計ガイド(以下『IPA ガイド』)」で整理した内容をベースに、各攻撃段階の手口や狙われる脆弱性 について説明する(「⑦再侵入」については、前段までと同様の行為の繰返しであるため、省略す る)。 図 1.2.-1 攻撃シナリオにおける攻撃段階

① 計画立案段階

計画立案段階では、攻撃者が一連の戦術の基となる情報収集を行う。 図 1.2.-2 計画立案段階のイメージ  脅威 攻撃者は、ターゲットとする組織のユーザがどのようなサイトにアクセスするのか、どのよう なメールを送ると開封する確率が上がるのか、周到に情報を収集する。  攻撃者が狙う情報 業務に関連した情報が入手できるとターゲットを騙しやすい。関連する組織への侵入や組織の ウェブページなどから、メール文面や職場関連の情報が収集される。 • 攻撃目標設定 • 関連調査 社外インターネットエリア 社内ネットワーク ①計画立案 ②攻撃準備 ③初期潜入 • 標的型メール • ウェブサイト改ざん • C&Cサーバ準備 ・標的型メール の送付 ⑦再侵入 ・バックドアを通じ 再侵入 ④基盤構築 ・バックドア開設 ・端末情報入手 ・構成情報入手 ⑤内部侵入 ・調査 ・他端末侵入 ・サーバ侵入 ・管理者情報窃取 ⑥目的遂行 ・情報窃取 ・システム破壊

(6)

5

② 攻撃準備段階

攻撃準備段階では、システム内部に侵入するための攻撃環境が作られる。 図 1.2.-3 攻撃準備段階のイメージ  脅威 攻撃者は、システム内部侵入後の攻撃基点となるC&Cサーバ3を準備する。C&Cサーバは、イ ンターネット上に構築され、端末の制御やターゲット組織から窃取した情報の一時保管にも用 いられる。また、計画立案段階で入手した情報を基に、ターゲットユーザが騙されやすい文面 を作り、標的型メールが作成される。場合によっては、マルウェア配布手段として、ウェブサ イトの改ざんも行われる。  脅威を増大させるインターネットの特性 C&C サーバは、国内に限らず世界中のサーバにホスティングされており、頻繁に攻撃拠点を 変えることで、攻撃元を特定しにくくしている。匿名性や簡単にサーバ構築が行えるインター ネットの仕組み自体が攻撃に悪用されており、本段階における対策を困難にしている。

③ 初期潜入段階

ターゲットユーザに対して攻撃が開始される。攻撃者は、メールやウェブ経由でマルウェアをユ ーザの端末に感染させる。 図 1.2.-4 初期潜入段階のイメージ

3 Command and Control サーバの略。攻撃者がマルウェアに対して指令となるコマンドを送信し、マルウェア感

染した端末の動作を制御するために用いられる。

○○社

改ざんウェブサイト 標的型メール

(7)

6  脅威 改ざんされたウェブサイトや標的型メールを経由して、ユーザの端末に潜入する。いずれも、 ウェブ画面やメール文面に違和感はないため、ユーザはマルウェアに感染したことに気づきに くい。  攻撃者が期待する脆弱性

この段階の脅威は、Internet Explorer(以下 IE)や JRE、Acrobat Reader などのクライア ントソフトウェアの脆弱性を悪用して、マルウェア感染に至らしめる。または、ユーザにメー ルを開かせるような文面を送り付けるなど、人の心理的な脆弱性も悪用される。

④ 基盤構築段階

マルウェア感染した端末にバックドアが開設され、攻撃者が端末を遠隔操作し、システム内部の 情報を収集できる状態が作られる。 図 1.2.-5 基盤構築段階のイメージ  脅威 攻撃者は、本格的な内部侵入活動に備えて、侵入した端末から次のような情報を収集する。 ①ID/パスワード ②システム構成、レジストリの情報 ③ファイル共有サービスが開いている周辺端末のIP アドレス システム内部への侵入(攻撃者によるユーザ端末の遠隔操作)が想定されていないシステム環 境では、比較的容易に情報収集が行われ、攻撃者が内部を探索した痕跡が残りにくい。  攻撃者が期待するシステムの脆弱性 この段階まで進むと、ソフトウェアの脆弱性を悪用しなくても、攻撃ツールを使用することで システムを攻略できてしまうことがある。すなわちち、ツールを使って探索できるシステム環 境そのものが、脆弱性(設計・運用上の弱点)と言える。次のようなシステム設計である場合、 攻撃者にとって攻略しやすい環境となる。 ①権限の高いアカウントの広範な使用 権限の高いアカウントを窃取することにより成りすましが容易となり、後続のシステム 攻略が行いやすい。 ②プロキシを通らないシステム設計 遠隔操作のためのバックドアが容易に開設され、痕跡も残りにくい。

(8)

7

⑤ 内部侵入・調査段階

攻撃者は、前段階で収集したシステム構成情報に基づき、システム内部の諜報範囲を拡大してい く。 図 1.2.-6 内部侵入・調査段階のイメージ  脅威 諜報範囲の拡大に当たっては、次の手口が用いられる。 ①ファイル共有サービスを悪用し、諜報範囲を拡大する ②諜報範囲の拡大過程でさらにID/パスワードを入手する ③②の中で、サーバメンテナンス用の管理者アカウントが存在した場合、サーバに対して 侵害活動が行われる。  攻撃者が期待するシステムの脆弱性 次のようなシステム設計である場合、攻撃者にとって攻略しやすい環境となる。 ①ファイル共有サービスが多用されている ②ユーザセグメントにサーバメンテナンス用の運用管理端末が接続されている - ユーザセグメントからサーバセグメントへの攻撃が容易に行えてしまう ③ユーザセグメントからサーバメンテナンス用のサービス4にアクセス可能 - サーバへの内部侵害が容易になってしまう この段階でも、ソフトウェアの脆弱性を悪用せずとも攻撃の段階を進めることができ、悪用さ れるのは“攻略が容易な”システム環境である。 4 SSH,FTP,リモートデスクトップ等のリモートメンテナンス用のサービス ファイルサーバ

ユーザセグメント

サーバセグメント

Active Directory 指令 ID/PWを窃取しながら端末 やサーバへ侵入を拡大 侵入拡大

Internet

(9)

8

⑥ 目的遂行段階

攻撃者は、システム内部に潜伏し、諜報範囲を拡大しながら、情報を外部に送信する。 図 1.2.-7 目的遂行段階のイメージ  脅威 攻撃検出を免れるために、手の込んだ送信手口が用いられている。例えば、窃取したファイル を情報集約用の端末に集め、圧縮し、小さな複数のファイルに分割して、情報送出用の端末群 から分散して外部に送出する。  攻撃者が期待するシステムの脆弱性 攻撃がこの段階まで進行すると、次の要因から攻撃の発見が難しい。 ① 攻撃による通信と正常通信の区別が困難 - オープン化が進み、多様な業務システムが稼動するインフラでは、業務通信のホワイト リスト化が困難であり、攻撃者は大量の業務通信に紛れて少量の不正な通信を発生させ、目的 を遂行する。

インターネット セグメント

中継SV群

FW

DMZ

Webサーバ

サーバー セグメント

Active Director y MAILL サーバ (SMTP ) グルー プ ウェア

フロアセグメント

本館 1-3F

東館 1-4F

基幹SW

運用管 理サ-バ プロキシ サーバ

インターネット

西館 1-4F

1次着弾

端末

拠点端末 情報収集

端末

情報送信

端末

ファイル サーバ ログ 管理

(10)

9

1.3. 設計・運用上の弱点

標的型攻撃は、メールやウェブと言ったオフィスワークで必須となる通信経路を使い、直接ユー ザ端末などのエンドポイントに対し攻撃を行ってくる。システムへの侵入を完全に防ぎきることは 難しいため、システム侵入を前提とした内部対策も併用することが重要になってくる。内部対策を 実施するためには、システムの設計・運用上の弱点(設計上の不備)を理解することが必要である。 以下に、現在のシステム設計で見落としがちな設計・運用上の弱点についてまとめる。

◆設計上の弱点

システム設計時の想定脅威が、インターネットからのみになってしまっており、内部侵 入を前提とした設計になっていない。そのため、攻撃者が取り得る侵入経路が複数あり、 センサーを設置しようにも設置場所が特定できない。 ユーザ端末と運用管理端末を共用しているため、攻撃者が高い権限を有したアカウント を窃取しやすい。

◆運用上の弱点

攻撃観測のトリガーや分析に必要なログの運用設計がされていない。 配置した各種製品ソリューションが行う多様な通信(システム設計者も把握できていな い)が多く、業務通信と不正通信を識別することができない。

(11)

10

2. 設計上・運用上の弱点を生む 10 の落とし穴

前述したとおり、脅威シナリオには、段階ごとに悪用される脆弱性があり、ソフトウェアの脆弱 性だけでなく、システム設計・運用上の弱点が狙われる傾向にある。また、攻撃全体の特徴として、 攻撃の初期段階ではソフトウェアの脆弱性が悪用される頻度が高いが、内部侵入後はシステム設 計・運用上の弱点が狙われる傾向にある。一般にWindows Update に代表されるように、ソフト ウェアの脆弱性については対策として浸透しているが、システム設計・運用上の対策については、 認知度が決して高くなく、対策が行われていないケースが散見される。 図2.-1 は、IPA のセミナーにおいて、システム設計状況についてアンケートを実施した結果であ る。 図 2.-1 システム設計対策実施状況 アンケートの質問は、内部侵入を許してしまう設計・運用上の弱点への対策状況である。質問に 対して、「実施している」と回答した組織は、概ね半分程度であり、対策として十分に浸透してい ない傾向が見て取れる。 本章では、標的型攻撃の脅威モデルに照らし合わせて、システム設計・運用上の意外な弱点を生 み出す要素を「10 の落とし穴」と称して以降にて説明する。 ◆10 の落とし穴  落とし穴①:メールチェックとサーバ等の運用管理用の端末が同一  落とし穴②:分離できていないネットワーク  落とし穴③:止められないファイル共有サービス  落とし穴④:初期キッティングで配布される共通のローカルAdministrator  落とし穴⑤:使いこなせないWindows セキュリティログ  落とし穴⑥:パッチ配布のためのDomain Admin  落とし穴⑦:ファイアウォールのフィルタリングルール形骸化  落とし穴⑧:不足している認証プロキシの活用とログ分析  落とし穴⑨:なんでも通すCONNECT メソッド  落とし穴⑩:放置される長期間のhttp セッション 0 5 10 15 20 25 30 3.全社的にセグメント分離とアクセス制御をしていますか? 2.プロキシログから不正な通信をチェックしていますか? 1.運用に専用端末を使用していますか 実施している 一部実施している 実施していない わからない 未回答

対策とし

て不十分

(12)

11

2.1. メールチェックとサーバ等の運用管理用の端末が同一

■ 運用背景

業務最適化の観点で、メールチェックなどの通常業務とサーバのメンテナンス業務が同じ端末 で実施されているケースが多い。攻撃者からしてみれば、メールやウェブ経由で端末に侵入で き、端末に保存されている管理者権限を使い、サーバまで攻略しやすい環境と言える。情報シ ステム部門がメンテナンス専用端末でのサーバメンテナンス業務を整備したとしても、予算管 理が縦割りになっている組織においては、組織全体に徹底するには至っていない。

■ リスク

通常業務と運用管理端末が同一の状態では、攻撃者がサーバメンテナンス用の高い権限を有し たID/パスワードを入手しやすい。一方で、一人一台の運用が正しいと推奨された現状では、 危険性だけを注意喚起しても組織全体で解消するには至らない。 図 2.1.-1 端末を悪用した攻撃イメージ

■ 対策

運用管理端末が狙われることを前提に、端末の分離とネットワークのアクセス制御を実現する ことで、侵害が運用サーバまで及ぶことを阻止する。また、攻撃者にメンテナンス用のサービ スやID/パスワードを見せないことで、脅威に対して効果的に対抗できる。 ユーザ端末と運用管理端末の分離 (詳細⇒IPA ガイド 2.2.6) ネットワークの分離設計とアクセス制御 (詳細⇒IPA ガイド 2.2.7) ユーザ兼 運用管理端末 運用サーバ群

(13)

12

2.2. 分離できていないネットワーク

■ 運用背景

ネットワークセグメントは分離しているが、ネットワークセグメントごとのアクセス制御は実 施するに至っていない。また、運用管理用セグメントが明確に設計されていないため、ユーザ セグメント5からサーバの業務用のサービス(httpやsmtpなど)の他にメンテナンス用のサー ビス(sshやリモートデスクトップなど)もアクセス可能な状態である。この様な状態で運用 していると、ユーザセグメントに侵入した攻撃者が、容易にサーバセグメントまで攻略できて しまう。

■ リスク

ネットワークセグメントが、アクセス制御まで含めて正しく設計されてない環境では、ユーザ セグメントに侵入した攻撃者がサーバメンテナンス用のサービスにアクセスできてしまう。一 方で、ネットワークセグメントの分離にのみ着目してしまっている環境では、危険性だけを注 意喚起しても組織全体で解消するには至らない。

■ 対策

全社的に下記のようなネットワークセグメント間のアクセス制御設計を実施し、攻撃者が諜報 範囲を拡大しにくいネットワーク構成を作り上げることが重要となる。 ネットワークの分離設計とアクセス制御 (詳細⇒IPA ガイド 2.2.7) 表 2.2-1 アクセス制御設計の例 アクセス先セグメント インター ネット DMZ サーバ ユーザ (一般) ユーザ (機密) 運用 管理 ア ク セ ス 元 セ グ メ ン ト インターネット ○ × × × × DMZ ○ ○ × × × サーバ ○ ○ × × × ユーザ(一般) × × ○ × × ユーザ(機密) × × ○ × × 運用管理 × ○ ○ × × 5 組織のネットワークにおいて、ユーザ部門が属するネットワークセグメントを指し示す。

(14)

13

2.3. 止められないファイル共有サービス

■ 運用背景

スキャンして紙ファイルをPDF 化する業務や P2P のファイル共有など、通常業務にファイル 共有サービスを取り入れている組織は少なくない。また、Active Directory はファイル共有サ ービスを利用してポリシーを配布しており、ファイル共有サービス自体を停止するのは、運用 上難しい。

■ リスク

ファイル共有サービスが利用されている環境では、攻撃者が諜報範囲の拡大を行いやすい。特 に「2.4.初期キッティングで配布される共通のローカル Administrator」で入手した全端末共 通のアカウント(ID/パスワード)を使用していた場合、ファイル共有は攻撃者にとって恰好 の餌食となってしまう。一方で、ファイル共有サービスを通常業務として活用している環境で は、危険性だけを注意喚起しても組織全体で解消するには至らない。特に、Active Directory によるドメイン環境を構築している場合は、ファイル共有サービス禁止の徹底は難しい。 図 2.3.-1 止められないファイル共有サービスのイメージ

■ 対策

ファイル共有は、特定のサーバとクライアント間に限定する運用を検討する。運用上、必要な いのであれば、ユーザ端末間のファイル共有サービスを禁止しておく。 ユーザ端末間のファイル共有の禁止 (詳細⇒IPA ガイド 2.2.9) ユーザ端末 ユーザ端末 ユーザ端末

(15)

14

2.4. 初期キッティングで配布される共通のローカル Administrator

■ 運用背景

規模が大きくなればなるほど、ユーザ端末の初期キッティング6時にクローニング7を利用し て構築するケースが増える。クローニングすると、ローカルのAdministratorアカウントが全 端末で共通のID/パスワードを有することになる場合がある。

■ リスク

Administrator アカウントが全端末で共通のパスワードの状態では、攻撃者が侵入したユーザ 端末からパスワードを入手し、他端末へ諜報範囲の拡大が容易になる。一方で、クローニング で初期キッティングを効率的に実現している現状では、危険性だけを注意喚起しても組織全体 で解消するには至らない。 図 2.4.-1 初期キッティングで配布される共通のローカル Administraor のイメージ

■ 対策

初期キッティング時において、共通のローカルAdministrator アカウントを使用しない運用を 徹底する。共通のアカウントを使用したい場合は、Administrator を避け別のアカウントとし、 サーバ側で監視と分析を実施する。 トラップアカウントによる認証ログの監視と分析 (詳細⇒IPA ガイド 2.2.10) 6 組織の環境に合わせて、業務アプリケーションがインストールされる端末の初期設定を指し示す。 7 OS やアプリケーションソフトなどを、設定などを含め全く同じ状態で別のコンピュータに丸ごと複製し、複製 先で同じように動作させること。

(16)

15

2.5. 使いこなせない Windows セキュリティログ

■ 運用背景

セキュリティに関するログ(認証ログなど)は、「しっかり取得すること」と、あらゆる基準 類に記載がある。しかし、具体的に何を取得するのかまでは掘り下げが不足している。特に、 Windows における認証試行は、イベントログ-セキュリティログとして出力されるが、量が多 くインシデントハンドリングに至らない。

■ リスク

Windows セキュリティログを使いこなせない環境では、Active Directory に対する不正な内 部アクセスを見逃してしまう。どのようにWindows セキュリティログを活用し、運用を意識 した注意喚起を行わないと、セキュリティのインシデントハンドリングまでには至らない。 図 2.5.-1 使いこなせない Windows セキュリティログのイメージ

■ 対策

攻撃者は、端末のアカウント情報を窃取して、ログイン要求を行う。ログイン要求には、正規 アカウントが用いられており、大量のログの中から不正アクセスの兆候を発見するのは困難で ある。そのため、偽のトラップアカウントを端末にキャッシュさせておき、攻撃者に偽のアカ ウントによる認証要求を発生させることで、攻撃のトリガーとして検知することが可能となる。 また、ログ分析の対象が、特定のトラップアカウントに限定できるため、調査や検知が効率的 に行える。 トラップアカウントによる認証ログの監視と分析 (詳細⇒IPA ガイド 2.2.10) Active Directory

・・・・・・・

・・・・・・・

・・・・・・・

・・・・・・・

認証ログ システム管理者

(17)

16

2.6. パッチ配布のための Domain Admin

■ 運用背景

パッチ配布は、セキュリティ要件で強く推奨されている。リモートからパッチ配布のために管 理者権限が必要な場合があり、Domain Admin権限8が使われている。

■ リスク

パッチ配布はセキュリティ上必要であるが、パッチ配布をDomain Admin 権限で実施してい る環境では、Domain Admin のアカウント情報が端末にキャッシュされているため、攻撃者 が侵入したユーザ端末からDomain Admin の ID/パスワードを入手できてしまう恐れがある。

図 2.6.-1 パッチファイルのための Domain Admin のイメージ

■ 対策

通常、パッチ適用のためだけにDomain Admin 等の権限の高いアカウントは必要ない。 Domain Admin の利用に際しては、特定の端末上のみに限定した使い方を行い、攻撃者に窃 取されるリスクを低減する必要がある。 高い管理者権限アカウントのキャッシュ禁止(限定的な使用) (詳細⇒IPA ガイド 2.2.8) 8 Active Directory の管理者権限。 ユーザ端末 Active Directory Domain Admins

(18)

17

2.7. ファイアウォールのフィルタリングルール形骸化

■ 運用背景

システム運用当初は、全ての通信がプロキシサーバを経由するように設計されていても、運用 の経過と共に、ファイアウォールのフィルタリングルールは緩くなり、当初のポリシーからか け離れてしまう。特に、アプリケーションを開発する部門の申請を受けると、ファイアウォー ルを管理するインフラ部門は開けざるを得ない。

■ リスク

ファイアウォールのフィルタリングルールが形骸化した環境では、マルウェアが外部のC&C サーバとのバックドアを開設しやすい。また、バックドアの通信はルールに則った正常通信と なるため、発見や事後分析が困難になる恐れがある。一方で、アプリケーションを開発する部 門においては、アプリケーションの動作・検証に様々な通信が必要となることがあり、危険性 だけを注意喚起しても「業務に必要」の一言で制限には至らない場合がある。 図 2.7.-1 ファイアウォールのフィルタリングルール形骸化のイメージ

■ 対策

近年のアプリケーションは、ほとんどがウェブプロキシを経由する通信に対応している。その ため、フィルタリングルールの見直しを行い、全ての通信をウェブプロキシ経由とし、ウェブ プロキシに対応できていないマルウェアの通信を検知しやすい構成とする。 一方でウェブプロキシに対応できていないアプリケーションも少なからず存在する。必要に応 じて通信を許可し、定期的にファイアウォールの通信ログを分析し、バックドア通信の発見に つなげる運用が求められる。 ネットワーク通信経路設計によるファイアウォールでのバックドア通信の遮断 (詳細⇒IPA ガイド 2.2.1) FW プロキシ

Internet

正常なサービス通信 マルウェアの通信 C&Cサーバ

(19)

18

2.8. 不足している認証プロキシの活用とログ分析

■ 運用背景

認証プロキシを導入し、ユーザの利用状況把握や監査のためだけに利用している場合がある。 その他に、ユーザへの利便性を考慮し、認証プロキシをNTLM認証9によるシングルサインオ ン環境で動作させている環境や、オートコンプリート機能によってID/パスワード入力を自動 化している環境が散見される。

■ リスク

認証プロキシがNTLM 認証によるシングルサインオンで動作している環境では、マルウェア が外部のC&C サーバとバックドアを開設する脅威に対して何ら効果がない。また、オートコ ンプリート機能により、ID/パスワードが端末に保存されている環境では、マルウェアに ID/ パスワードを入手されてしまうため効果が薄い。認証プロキシ導入が目的になってしまってい る組織に関しては、導入を推奨するだけでは対策までには至らない。 図 2.8.-1 不足している認証プロキシの活用とログ分析のイメージ

■ 対策

認証プロキシサーバに対応できていないマルウェアも一定の割合で存在する。また、認証プロ キシを通過するマルウェアにおいては、端末上に保存されているID/パスワードを窃取した上 で、認証突破を試みる。そのため、認証プロキシを導入し、認証ログの結果から認証突破を試 みるマルウェアの通信を発見しやすくすることが、バックドア発見のためにも重要である。以 下のような対策が有効である。 プロキシサーバの認証機能によるバックドア通信の遮断(詳細⇒IPA ガイド 2.2.3) ブラウザのオートコンプリート機能の禁止 (詳細⇒IPA ガイド 2.2.3) ネットワーク通信経路設計によるファイアウォールでのバックドア通信の遮断 (詳細⇒IPA ガイド 2.2.1) 9旧式のネットワークログオンのためのユーザ認証方式。 プロキシ (認証機能付)

Internet

FW

認証

OK

C&Cサーバ

(20)

19

2.9. なんでも通す CONNECT メソッド

■ 運用背景

HTTPのCONNECTメソッド10は、HTTPSなど通常の業務通信でも利用されているため、特 に通信制限が行われていない。

■ リスク

CONNECT メソッドが利用できる環境では、マルウェアが外部の C&C サーバとのバックド アを開設しやすい。また、大量の通信ログとなるため、マルウェア通信の発見や事後分析が困 難になる恐れがある。 図 2.9.-1 なんでも通す CONNECT メソッドのイメージ

■ 対策

CONNECT メソッドは、HTTPS(443 ポート)に代表される特定のプロトコルに限定されて 使用されるケースが多い。一方でマルウェアの通信は、独自プロトコルやランダムなポートへ のアクセスが多く、業務を阻害しない範囲で不要なCONNECT メソッドの通信を制限するこ とで、バックドアの遮断につなげることができる。 プロキシサーバのアクセス制御によるバックドア通信の遮断 (詳細⇒IPA ガイド 2.2.2) 10 SSL の暗号化通信等において、プロキシサーバにトンネリング要求をするための HTTP1.1 の機能。一部のマル ウェアは、コネクトメソッドを悪用して、外部接続することが分かっている。 正常なサービス通信 マルウェアの通信 プロキシ

Internet

FW CONNECT要求 CONNECT要求/SSL通信

(21)

20

2.10. 放置される長期間の http セッション

■ 運用背景

長時間にわたって張りっぱなしのhttp セッションに対し、監視の重要性を感じていないケー スが多い。また、組織のインフラは24 時間 365 日利用可能との共通認識が広まっている現状 では、業務を阻害してしまう恐れがあるため、遮断はできない。

■ リスク

長期間のhttp セッションが利用できる環境では、マルウェアが C&C サーバとの通信を維持 しやすい。また、再接続が行われないことより、ログが少量となり、発見や事後分析が困難に なる恐れがある。 図 2.10.-1 放置される長期間の http セッションのイメージ

■ 対策

定期的に通信を強制切断することで、機械的に再接続しようとするマルウェア通信の発見につ なげやすい。全組織一斉に強制切断することが難しい場合は、部門毎に分けて定期的に強制切 断のテストを実施すると良い。 プロキシサーバ経由通信強制遮断によるバックドア通信の発見 (詳細⇒IPA ガイド 2.2.5) プロキシ

Internet

FW C&Cサーバ

(22)

21

3. 脅威の全貌をふまえた対策の考え方

「1.2. 脅威が期待する段階ごとの脆弱性」で紹介した一連の攻撃シナリオに沿って、個々の攻撃 を無効化するための対策を講じる必要がある。また、対策は攻撃の「入口」「エンドポイント」「出 口」「内部」と攻撃者の通り道に適切な対策を施し、最終的な被害を回避することが重要となる。

3.1. 対策の全体像

対策立案にあたっては、攻撃段階ごとに想定脅威を洗い出して検討してほしい。各攻撃段階に応 じた対策を多層的に講じる防御思想を取り入れることが重要となる。 図 3.1-1 攻撃シナリオと対策全体像 上記は攻撃シナリオと、それに対応する大まかな対策を対比した図である。初期潜入、バック ドア開設までは、脆弱性の悪用やマルウェアによる攻撃が行われるため、セキュリティ製品を配 置して防御するのが一般的である。一方で、バックドア開設後は、攻撃者が内部の端末を遠隔操 作して不正アクセス(ハッキング)を仕掛けてくるため、ネットワーク設計やアカウント権限の 最小化等のシステム設計・運用による防御が重要となってくる。 攻撃シナリオの、「③初期潜入」から「⑥目的遂行」までのできるだけ早い段階で攻撃を 検知することで、被害を局所化でき、最終的な攻撃目的の達成を回避できるという発想 が、昨今の脅威に必要である。

(23)

22

3.2. 攻撃シナリオと対応機器の関係

個々の攻撃から防御するための機器を攻撃シナリオに合わせて示す。標的型攻撃に限らず、一連 のサイバー攻撃に対処するには、攻撃を「検知」、「遮断」でき、被害の詳細を確認するための「追 跡」が行える状態を整備する必要がある。各々の機器の特性を踏まえて、運用まで見据えたシステ ム・運用設計することが求められている。 表 3.2-1 攻撃シナリオと対応機器の概要 標的型攻撃への対処は、セキュリティ製品だけでなく、システム設計に基づく対象機器 設定と組合せて、対策を講じることが重要である。 ス パム フ ィ ルタ S PF 次世代サン ド ボ ッ ク ス 型 フ ァ イ ア ウ ォ ー ル メ ー ル サ ー バ イン タ ー ネ ッ ト フ ァ イア ウ ォ ール IP S / ID S 次世代 ウ ェ ブ ア プ リ ケ ー シ ョ ン フ ァ イ ア ウ ォ ー ル ウ ェ ブ サ ーバ ウ ェ ブ 改ざ ん 検知 ウ イ ルス 対策ソ フ ト ゼ ロ デ イ 対策ソ フ ト ウ ェ ブプロ キ シ サ ー バ ウ ェ ブ フ ィ ル タ リ ング 次世代型ネ ッ ト ワ ー ク 振る 舞い 検知型  F W / ID S / IP S 業務端末 運用管理端末 内部セ ン サー 認証サー バ フ ァ イ ルサー バ D Bサ ー バ 監視サー バ ネ ット ワ ー ク 機 器 1 計 画 立 案 2 ○ ○ ○ 3 4 5 △ △ ○ □ △ ○ 6 ○ △ ○ 7 ○ ○ ○ △ △ □ □ 8 9 端末内のシステム 情報を収集 △ ○ □ □ 10 攻撃ツールの ダウンロード ○ △ ○ ○ ○ □ □ 11 周辺端末調査 △ □ □ ○ 12 ○ □ □ ○ 13 ○ □ □ ○ ○ ○ 14 ○ □ □ 15 ○ ○ □ □ 16 □ □ ○ 【凡例】 ○:攻撃検知(主観測) △:攻撃検知(補助) □:ログ取得機器 セキュリティ製品 業務機器 リモートコマンド実行 端末情報の収集 C&Cサーバ準備 標的型メール作成 エンドポイント 対策 他端末への不正アクセ ス 入口対策 内部対策 ターゲット周辺の調査 ウェブサイト改ざん、 水飲み場サイト構築 No.       対応機器 攻撃手口 バックドア開設・リモートコ ントロールの確立後 攻 撃 準 備 標的型メール受信 水飲み場サイトアクセス 初 期 潜 入 基 盤 構 築 段 階 内 部 侵 入 ・ 調 査 バックドア開設 目 的 遂 行 情報窃取 情報破壊 出口対策 入 口 対 策 出 口 対 策 内 部 対 策 エ ンド ポ イ ント

(24)

23

おわりに

本書では、標的型攻撃を中心としたサイバー攻撃の脅威と対策の考え方について紹介した。ご覧 いただいた様に標的型攻撃は、ソフトウェアの脆弱性や設計・運用上の弱点を狙い、戦術的にシス テム攻略が行われる。言うなれば、攻撃者は入念に作戦を練り、内部の様子を伺いながら、情報を 盗み取っていく。対策に当たっては、攻撃者に「手ごわい」「攻略しづらい」と思わせるシステム 設計が必要となってくる。なお、本書で紹介した対策は、あくまで一例であり、必ずしもこれらの 方法に固執する必要はない。重要なのは、脅威の全貌を把握した上で、自組織の運用の都合に合わ せ、攻撃を検知しやすく、あるいは無効化する対策を考えることである。「入口対策」、「エンドポ イント対策」、「出口対策」、「内部対策」と攻撃段階を自組織に当てはめてシミュレーションしなが ら、対策を検討していただきたい。 IPA では、標的型攻撃を含めたサイバー攻撃による被害の低減を目指して、下記のような取組み を実施している。  入口対策  標的型サイバー攻撃 特別相談窓口(http://www.ipa.go.jp/security/tokubetsu/)  「脆弱性対策データベース JVN iPedia」(http://jvndb.jvn.jp/)  エンドポイント対策  「MyJVN バージョンチェッカ」(http://jvndb.jvn.jp/apis/myjvn/index.html)  出口対策/内部対策  「標的型メール攻撃」対策 に向けたシステム設計ガイド IPA では、今後ともこれらの活動を継続し、最新の脅威に対応したセキュリティ対策を推進して いく。本書やIPA の取組みが、組織における効果的な対策を検討するうえでの一助になれば幸いで ある。

(25)

攻撃者に狙われる設計・運用上の弱点についてのレポート

~ 標的型攻撃におけるシステム運用・設計に係る

10 の落とし穴とその対策 ~

[発 行] 2014 年 3 月 28 日

[著作・制作] 独立行政法人情報処理推進機構 技術本部 セキュリティセンター [執 筆 者] 大森雅司、佳山こうせつ

図  2.6.-1  パッチファイルのための Domain Admin のイメージ ■  対策 通常、パッチ適用のためだけに Domain Admin 等の権限の高いアカウントは必要ない。 Domain Admin の利用に際しては、特定の端末上のみに限定した使い方を行い、攻撃者に窃 取されるリスクを低減する必要がある。 高い管理者権限アカウントのキャッシュ禁止(限定的な使用) (詳細⇒ IPA ガイド 2.2.8)

参照

関連したドキュメント

世界的流行である以上、何をもって感染終息と判断するのか、現時点では予測がつかないと思われます。時限的、特例的措置とされても、かなりの長期間にわたり

定可能性は大前提とした上で、どの程度の時間で、どの程度のメモリを用いれば計

システムであって、当該管理監督のための資源配分がなされ、適切に運用されるものをいう。ただ し、第 82 条において読み替えて準用する第 2 章から第

キャンパスの軸線とな るよう設計した。時計台 は永きにわたり図書館 として使 用され、学 生 の勉学の場となってい たが、9 7 年の新 大

光を完全に吸収する理論上の黒が 明度0,光を完全に反射する理論上の 白を 10

ALPS 処理水の海洋放出に 必要な設備等の設計及び運 用は、関係者の方々のご意 見等を伺いつつ、政府方針

の主として労働制的な分配の手段となった。それは資本における財産権を弱め,ほとん

この設備によって、常時監視を 1~3 号機の全てに対して実施する計画である。連続監