情報処理安全確保支援士 2016年 春期 午後II 問題

共通の文章

CSIRT構築とセキュリティ設計に関する次の記述を読んで,設問1て6に答えよ。 A社は,従業員数3.000名の独立系ソフトウェア開発会社である。受託開発業務が 中心であるが,一部の部署で展開しているサービス事業が拡大傾向にある。 (A社の組織] A社には,公共事業部,製造事業部,開発事業部,管理統括の四つの組織がある。 公共事業部と製造事業部は,それぞれの業種の顧客システムの開発が事業の中心で HS,開発事業部には,公共及び製造以外の業種の顧客システムの開発を行う部署 と,A社独自のサービス事業を行う部署とがある。後者のうち,ソリューションサー ビス部(以下,SS部という)は,国内の人材をデータベース化し,顧客企業に紹介 するWebサービス(以下,高度人材サービスという)を提供している。管理統括は, 人事部,総務部,情報システム部(QE,IT部という)などで構成される。 A社では,各事業部に事業部マネジメント(以下,事マネという)という組織があ り,事業部の実務的な意思決定を行っている。A社の組織図を図1に示す。 ー公共事業部製造事業部開発事業部管理統括 | mse ES ::開発第一部 注記“A社IRT”は,A社におけるCSIRTの呼称である。 図1 A社の組織図 [A社のセキュリティポリシ〕 AA社のセキュリティポリシでは。セキュリティイシッシデント(以下。インシデッシト という)発生時の対応を図2のように定めているが,どのような事象がインシデン トに該当するかは定義されていない。インシデントの報告を受け付けた際の,A社 IRTの運用手順の概要を表1に示す。 ーー3—_ インシデントハンドリング ・A社で発生したインシデントは,A社IRTが対応を主導する。 ・インシデント発生時の報告受付窓口を,A社IRTに設置する。 ・従業員がインシデントを発見した場合には,必ずA社IRTに報告する。 ・A社ITRTはインシデント報告を受け付けると,情報セキュリティの専門的な知見を基に,定め られた運用手順に従って活動し,該当する部署又は事マネに対して対応の指示を行う。個々の 作業の記録を残し,報告の受付から完了までをインシデントごとに管理する。 コーディネーション ・A社IRTは,報告受付後,インシデント対応に関して社内外の組織と次のような連携を行う。 -インシデントの発見者に情報提供などを依頼し,受け付けた内容の事実確認を行う。 -インシデントの重要度やインシデント対策の必要性に応じて社外の専門家に調査を依頼す る。 (以下,省略) 図2セキュリティポリシ(抜粋) 表1 A社IRTの運用手順(概要) a en eee 1|報告の受付|A社IRTは,インシデントの発見者からインシデン 2トリアージ|4社IRTは,受け付けた内容の事実確認を行った上[|。dca で,あらかじめ定めた基準に従い,重要度や優先度|CT,番号3又 を考慮して,| 。|を判断する。は番号6に進む 3|調査依頼検討|A社TRTは,インシデントを調査し,あらかじめ定|番号4に進む めた基準に従い,重大ながインシデントであり,か つ,必要性が認められた場合は,社外の専門家に調 査を依頼する。 4|状況報告検討|A社ITRTは,インシデントの対応内容を検討する。|番号5に進む あらかじめ定めた基準に従い,重大なインシデント は経営陣に状況を報告し,必要に応じて経営陣に意 思決定を依頼する。 5|対応指示A社ITRTは,あらかじめ定めた基準に従い,インシ|番号6に進む | の対応内容を決定し,必要な対応指示を行う。ま た,対応状況を適宜確認する。 ee eae 完了A社IRTは,当該インシデントに関する記録を整理 (A#t IRTの現状] IT部の部長をAt IRT責任者とし,IT部から選任した2名をA tt IRT担当者と する計3名がA社IRTのメンバであるが,3名とも兼務である。A社の従業員に対し て,A IRTの存在を積極的には周知しておらず,A社IRTに報告すべきインシデ =4— ントの範囲についても明確には定義していない。 多くの従業員は,セキュリティポリシに規定されたA社IRTの機能を知らなかっ た上に,社内Webサイト上に,“マルウェア感染時の社内の連絡先”の表記があるこ とから,A社IRTをマルウェア感染時の報告先だと認識していた。そのため,マル ウェア感染以外のインシデントが事業部で発生した場合は,A社IRTではなく事マ ネに報告していた。事マネはA社IRTにインシデントを報告せず,事業部内で対応 や判断を行っていた。 〔インシデント発生 HOA,高度人材サービスの管理者であるSS部のP主任が,見慣れないファイル が高度人材サービス用Webサーバ上にあることを発見した。P主任が,Webサーバ のログを確認したところ,インターネットからサイバパバー攻撃を受け,攻撃者が不正 にWebサーバにファイルをアップロードしていたことが分かった。しかし,攻撃者 のその後のコマンドは全て失敗しており,実害はないと判断した。P主任は,A社 IRTの存在を知っていたので,電子メール(以下,メールという)で状況を報告した。 A社IRT担当者からの返事は数日を要した。P主任は,TORS At IRT担当者と 何度かメールでのやり取りを行ったが,他の業務の繁忙期であったので返信が滞り, さらに,A社IRT担当者からのフォローもなかったので,本件はうやむおやとなった。 その数か月後,総務部の担当者宛てに,A社が出所と思われる,個人情報が含まれ た名短が出回っているとの問合せがあった。総務部の担当者が人事部に問い合わせ たところ,数日後,“人事部が保有する情報ではない。どこかの事業部が作成した名 和仁ではないか"との回答があった。総務部の担当者は,その後も幾つかの部署に問 い合わせてみたが,要領を得た回答が得られなかった。最終的には,IT部に相談し た際にA社IRTを紹介され,A社IRTに名邊を確認してもらうことになった。4A社 IRT担当者は,名簿の内容から高度人材サービスに関するものと推測し,IT BOR 務の合間にP主任にメールで問い合わせたところ,確かに高度人材サービス固有の 情報を含む名簿であることが分かった。A社IRT担当者が,P主任と協力して調査を 進めた結果,数か月前に高度人材サービスにサイバー攻撃があった時に,名簿情報 が不正に持ち出された可能性があることが分かった。A社IRT責任者は経営陣に状 況を報告した。調査に時間を要したので,総務部の担当者が連絡を受けてから2か ー5一 月が経過していた。経営陣は,漏えいした名答に個人情報が含まれている各人に, おわびと,その時点までに確認された状況の説明を郵送でするよう指示を出した。 この事件はマスコミが大々的に採り上げ,A社の情報セキュリティの組織的な取組 みのまずさや情報公開の遅さが批判された。A社の顧客や株主からの問合せは,経営 陣の想定以上のものがあり,結果的に社長による謝罪会見にまで発展した。本業で ある受託ソフトウェア開発事業への影響も大きく,経営的にも極めて大きな打撃を 受ける結果となった。経営陣は,A社のインシデント対応には重大な問題があると考 Ale [A社IRTの活動のアセスメントと改善] A社の経営陣は,社外のセキュリティコンサルタント会社のT社に,A社のイン シデント対応の現状のアセスメントを依頼し,問題点を洗い出してもらうことにし た。T社は,A社内の様々な関係者へのヒアリングや,過去のインシデント対応の記 録の調査,運用手順などのアセスメントを実施し,結果を報告書にまとめた。報告 書には,A社には多くの問題点が存在すること,及びその中で最も重要度が高い問題 点は表2に示すA社TIRTに関する問題点であることが明記されていた。 表2 A社IRTに関する問題点(抜粋) 問題点 AB・A社IRT責任者は,情報セキュリティに関する知識や経験が不足している。 ・A社IRT担当者は,A社IRT以外の業務が恒常的に忙しく,運用手順に従っ た対応ができていない。 A社IRTの存在と機能がA社内に十分には周知されていない。 対応指示手順|表1の運用手順における“対応指示"手順と異なり,現状はインシデントを発 見した事業部が独自に影響度を判断し,事業部の都合を優先させた対応を行っ ている。A社IRTは対応を記録すること,及び対応の完了を確認することしか していない。 T社は,現状のA社ITRTの人員では,A社IRTの機能を適切に遂行することに無 理があるので,A tHe IRTの人員を見直すよう経営陣に提言した。また,その他の問 題点についてもそれぞれ改善策を提言した。 経営陣は,T社の提言に従い,優先度が高い幾つかの改善策を実行することにした。 ーー6ーー 最初に,A社IRTをIT部から独立させて経営陣直属の組織とし,A社IRT責任者に は,経営陣の中から情報セキュリティに知見がある者を就任させた。また,①表1 における対応指示は,A HIRTが直接行えるようにした。 次に,A社IRT担当者には,情報セキュリティスペシャリスト資格をもつ,ベテ ランのU BRL,その部下であるYさんを割り当て,専任とした。U課長は, [|b|の明確化や周知の改善などを行い,表2の問題点への対策を完了した。さ らに,経営陣は,従業員の情報セキュリティの意識改革についても積極的に取り組 み,A社は,インシデント対応を適切に遂行できる組織となった。 [A社のネットワーク構成 A社では,OA APC,ネットワーク機器,サーバ,OS,ミドルウェア,アプリケ ーション(以下,情報機器という)をIT部が管理している。また,それとは別に各 部署が独自に管理する情報機器もある。ネットワークは,全て固定されたIPアドレ スで運用されている。各部署が独自にインターネット回線や情報機器を調達する際 は,IT部に届け出るルールになっている。その際,IT部から,A社に導入実績があ るシステム構成を紹介されるケースが多いので,同一ベンダのサーバやミドルウェ アがA社では多く採用されている。A社のネットワーク構成を図3に,情報機器の 概要を表3に示す。 『 コットー利用者LAN= ssi reall srr?| >|IA部メー We:ム靖WebサーバNSS部独自LANーー=| Webサーバ管理用LDAPファイル Dae Tae Rae 注記FW1とFW2は同一ベンダのアプライアンスである。 図3 A社のネットワーク構成(抜粋) 表3情報機器の概要(抜粋) OA FA PC・各従業員に1台ずつつ貸与され,資料作成,Web閲覧,メール送受信などに利 用される。 ・次の認証情報でログインする。 PC ID:数字6桁で構成された,PCを識別する固有の番号である。 パスワード:OA用PCが従業員に貸与された後,初期パスワードを徒業員 自らが変更する。 LDAPサーバA社従業員の次の認証情報などを保管し,様々なシステムからのLDAPクエ リに応答する。 LDAP ID:8桁の英数字で構成された従業員IDであり,A社の各従業員に付 与きれている。 パスワード:LDAP IDを従業員に通知後,初期パスワードを従業員自らが変 更する。 ・IT部の運用チームが管理を行う。HTTPでアクセスできる管理画面があり, 運用チーム4名のLDAP IDでだけログインできる。 FW1 IT部が管理する。一部の運用保守作業は外部業者に委託している。例えば, ポリシ変更の際は,IT部が外部業者に指示を出し,外部業者の担当者が遠隔 地からインターネットを経由し,SSHクライアントソフトを用いて更新作業 を行っている。 FW2・SS部が管理する。ポリシ変更は,FW2のコンソールポートに常時接続され たMPCからだけ許可されている。SS部の担当者がMPCにログインし, SSHクライアントソフトを用いて更新作業を行っている。 MPC・FW2を管理する専用のPC CHS,普段はOSの認証機能ことよってロックさ れており,SS部の一部の担当者だけがロック解除できる。 [A社のシステム運用]〕 IT部では,外部業者に委託している一部の運用保守を除き,DMZやサーバLAN のサーバなどのIT部が管理している情報機器の運用保守は,IT部のOA用PCから 実施している。例えば,LDAPサーバの場合は,OA用PCからHTTPで管理画面に アクセスし,運用チームのメンバに付与されたLDAP IDでログインした後,管理者 昇格コマンドと管理者パスワードを入力すると,IT部の運用チームだけに与えられ ている管理者権限が付与され,LDAP IDの追加,削除などを行うことができる。 IT部以外の部署が管理する情報機器は,各部署のルールで管理しており,LDAP サーバとは連携していない。 [マルウェア感染] A社IRTの再発足から半年たったある日,IT BAS A社IRTに,LDAPサーバの ーー8ーー ログに大量のサーバログイン失敗が記録されているとの報告が入った。システム障 害の原因調査中に,偶然発見したものであった。U課長が,運用手順に従って事実を 確認したところ,サイバー攻撃の可能性が高いことが分かり,セキュリティ専門業 者のR社に調査を依頼した。 R社が調査した結果,標的型攻撃メールを発端としたサイバー攻撃であることが確 認された。この攻撃には,A社で利用しているマルウェア対策ソフトでは検出できな いマルウェアが使用されていた。図4は調査によって明らかになった攻撃の概要で ある。、 ・攻撃者がマルウェアを添付した攻撃メールをSS部のZ主任に送信した。Z主任が添付ファイ ルを開いたことによってマルウェアが起動された。 ・マルウェアは,Z主任のOA用PC内の認証情報を取得してプロキシサーバを突破し,攻撃者 が準備したサーバ(以下,Kサーバという)にアクセスして新たなマルウェアをダウンロード した。このマルウェアによって,Z主任のOA用PCは攻撃者による遠隔操作が可能になっ Tes ・攻撃者は,Z主任のOA用PC上のメールフォルダやネットワークに関する情報を探索し,A 社のネットワーク構成情報などを取得した。 ・攻撃者は,Z主任のOA用PCから,他の複数のOA用PCをマルウェアに感染させた。 ・攻撃者は,Z主任のLDAP ID,及びマルウェアによって不正に取得した複数のLDAP ID OF 証情報を用いて,サーバLANの各サーバにアクセスを試み,ファイルサーバの一部のフォル ダへのアクセスに成功した。その後,複数のLDAP IDの認証情報を用いて,LDAPサーバの 管理画面からのログインを試みたが,いずれも失敗した。 ・攻撃者は,IT部の運用チームメンバのLDAP IDを入手し,当該LDAP IDのパスワードを入手 するためにLDAPサーバの管理画面でブルートフォース攻撃を行ったが,全て失敗した。 ・ブルートフォース攻撃の失敗以降は,攻撃者による遠隔操作は記録されていない。 図4攻撃の概要 A社IRTは,R社からの報告を受け,Kサーバへの通信の遮断に加え,マルウェア の駆除などの暫定処置を行った。A社IRTは社内外との連携も含め,運用手順どお りにインシデント対応を行った。 [セキュリティ設計の見直し] 経営陣は,今回の攻撃に対するA社ITRTのインシデント対応には一定の評価を与 えたが,A社内のシステムのセキュリティ設計には改善すべき点が多いと考えた。そ こで,以前,アセスメントを実施したT社の提言に含まれていたものの,未対応で —9ュー: あった“マルウェア感染を前提としたシステムのセキュリティ設計の見直し"をU 課長に指示した。U課長から指示を受けたYさんは,対策案を表4のようにまとめ た。 表4対策案(抜粋) マルウェア感染の拡大や,攻撃者に|対策(1-1)運用管理セグメントの新設 よる内部探索,内部侵入を困難にす|対策(1.2)パスワードの複雑さに関するポリシの導入 るための対策対策(1.3)サーバでのアカウントロック機能の有効化 対策(1-4)添付ファイル付きメールの送信元が社外である かどうかの識別性向上施策の導入 マルウェア感染の拡大や,攻撃者に|対策(2-1)サーバでのブルートフォース攻撃の検知 よる内部探索,内部侵入を早期に検|対策(2-2)FW1Iでのマルウェア通信の検知 知するための対策 Yさんは,各対策案について,IT部やその他の関係する各部署と調整しながら検 討を進めることにした。Milt,Yさんが対策(1-1)をIT MOHさんに説明した時の会 話である。 Yさん:運用管理セグメントの新設の検討をお願いします。運用管理セグメントとは, サーバLAN上のサーバを管理するために使用するPC(以下,運用管理PC という)を設置するセグメントであり,SSHなどの特定の管理用ポートを 用いて,運用管理PCからサーバLANの各サーバにアクセスします。利用 者LANからサーバLANへのアクセスについては,管理用ポートへのアク セスを禁止し,(HO PCから運用管理PCへのアクセスも禁止します。 Hさん:現状でもサーバLANの各サーバの管理用ポートへのアクセスは,利用者 LANのIT部のセグメントからしか許可を与えておらず,実質的には,運用 管理セグメントを新設することと同等のセキュリティが既に備わっている ので,運用管理セグメントの設置は不要だと思います。 これをYさんがU課長に報告したところ,U課長は,②@運用管理セグメントを新 設することによって,現状では防ぐことができない攻撃に対処できるようになるこ とをYさんに説明し,対策(1-1)の趣旨をIT部に改めて正しく伝えるように指示した。 次は,対策(2-1)に関するYさんとU課長の会話である。 Yさん:対策(2-1)についてですが,LDAPサーバにログインするための,パスワード に対するブルートフォース攻撃を検各するために,同一のLDAP IDによる 連続した認証失敗回数をカウントし,その回数が一定値を超過すると,ア ラートを発生させる仕組みを考えています。 U課長:今回の攻撃はブルートフォース攻撃であったが,次に攻撃を受けるときは, リバースブルートフォース攻撃を受けるかもしれない。リバースブルート フォース攻撃についても検知できる仕組みが必要だな。 Yさん:ご指摘も踏まえ,更に検討を進めます。 Yさんはその後,連続した認証失敗回数をカウントして攻撃を検知する方法に加え, リバースブルートフォース攻撃も検各できるよう,A社のLDAPサーバの運用管理 を考慮した新たな検知方法を考えた。 A社IRTは各部署との調整を進め,対策計画案を作成した。対策計画案は経営陣 の承認の上,実行されることになった。 (用弱性情報ハンドリング】 IT部は,IT部が管理する情報機器の脆弱性情報を.,インターネット上にあるベン ダのWebサイトや,脆弱性情報が記載されたWebサイトなどから収集している。脆 弱性修正プログラムは,重要度に応じて適宜適用している。一方,各部署が独自に 管理する情報機器の脆弱性情報の収集や脆弱性修正プログラムの適用は,部署ごと に対応が異なっており,多忙なときは,漏れてしまったり,遅くなつてしまったり するケースもある。 最近,A社では,各部署が独自に管理する情報機器の脆弱性修正プログラムの適用 漏れに起因するインシデントが増加傾向にあった。U課長は,A tH IRTが各部署の 脆弱性管理を支援すること(以下,脆弱性情報ハンドリングという)によって,こ の状況を改善できると考えた。具体的には,次のようにする。 ー]1一 ・SS部独自LANなど,部署独自LANの管理を各部署だけに任せるのではなく,A 社ITRTが,各部署の重要な脆弱性修正プログラムの適用状況を把握する。 ・A社が保有する情報機器の脆弱性情報をA社IRTが収集し,各部署に発信するこ とによって,各部署が脆羽性情報を収集する負担を低減し,A社全体で効率化する。 U課長は,A社IRTに脆弱性情報ハンドリング"機能をもたせるための,現状 の課題は図5の3点であると分析した。 re 課題2:情報機器の脆弱性情報を,ベンダのWebサイトや,脆弱性情報が記載されたWebサイ 課題3:収集した脆弱性情報に,各部署がどのように重要度や影響度を勘案して対応すべきかに ついて,A社としての指針が存在しない。 トから収集するには多くの工数が必要だが,現状の要員では対応ができない。 図5現状の課題 課題1については,短期的な対応は困難なので,当面はこれまでに各部署が作成 した情報資産台帳を入手することにした。長期的には,各部署の構成管理情報を自 動的に収集する仕組みを導入し,A tt IRTが各部署の構成管理情報を把握すること を目指す。 課題2については,長期的にはA社IRTを増員することによって対応する。短期 的には増員せず,④A社の各部署の取組みと連携して対応することによって,工数の 発生を最小限に抑える。 課題3については,汎用的で定量的な評価手法を用いた共通脆弱性評価システム のバージョン3(以下,CVSSという)を参考にする。CVSSは,三つの基準で脆弱 性を評価する手法である。一つ目は“基本評価基準"であり,機密性などのセキュ リティの特性や,ネットワークから攻撃が可能かといった攻撃元の特性からスコア を算出する。この基準は,時間の経過や環境の違いによるスコアの変化はない。ど こから攻撃可能であるかを評価する攻撃元区分を表5に示す。 ー12一 表5攻撃元区分 ネツドータクタ対象コンポーネントをネットワーク経由でリモートから攻撃可能である。 例えば,インターネットからの攻撃など 隣接対象コンポーネントを隣接ネットワークから攻撃する必要がある。 例えば,ローカルIPサブネット,ブルートゥース,IEEE 802.11など ローカル対象コンポーネントをローカル環境から攻撃する必要がある。 例えば,ローカルアクセス権限での攻撃が必要,ワープロのアプリケーション に不正なファイルを読み込ませる攻撃が必要など 物理対象コンポーネントを物理アクセス環境から攻撃する必要がある。 例えば,IEEE 1394,USB経由で攻撃が必要など 出典:独立行政法人情報処理推進機構共通脆弱性評価システムCVSS v3概説2.1.1.攻撃元区分 (AV:Attack Vector)から引用 (URL:https://www.ipa.go.jp/security/vuln/CVSSv3.html(平成28年3月8日アクセス)) ニン目は“現状評価基準”であり,攻撃コードの出現有無や対策情報が利用可能 であるかどうかを基にした評価基準である。ベンダなどの脆弱性への対策状況に応 じ,時間の経過によって変化し,脆弱性を公表する組織が,脆弱性の現状を表すた めに評価する基準である。 三つ目は“環境評価基準"”であり,ネットワーク環境やセキュリティ対策状況を 含め,攻撃元区分の再評価などによって,組織にとっての最終的な脆弱性の深刻度 を評価する基準である。 基本評価基準のスコアは脆弱性ごとに定まるが,環境評価基準は脆弱性が存在す る情報機器ごとにスコアが異なる。例えば,図3のFW1とFW2に関する,SSM 弱性が公表された場合,この脆弱性の基本評価基準のスコアに対して,評価時点の 現状評価基準のスコアを算出し,最後に,環境評価基準として,FW1とFW2のそれ ぞれで最終的な深刻度のスコアを算出する。U課長は実際に,FW1とFW2に存在す る,ある脆弱性の深刻度を算出してみた。この脆弱性は,FWのポリシ更新のコマン ド発行において,特定のパラメタを組み合わせると管理者権限がなくても不正にポ リシを更新できるというものである。環境評価基準において,FW1の攻撃元区分は であり,FW2の攻撃元区分は|ad|であぁることから,[se| のスコアがより高い値を示した。 A社ITRTが各部署に発信する脆弱性情報について,該当する情報機器を保有して いた場合には,各部署で深刻度を算出してもらい,一定値を超えた場合は,A tt IRT に脆弱性の対応計画を提出する仕組みにする。 U課長の脆弱性情報ハンドリングに関する提案は,A社IRT責任者及び経営陣に よって承認され,A社IRTは,A社全体の情報セキュリティを担う,より高度な組織 がつた。

共通の文章

テレワークのセキュリティに関する次の記述を読んで,設問15に答えよ。 Q社は,従業員数700名のシステムインテグレータである。東京,名古屋及び大 阪に事業所がある。各事業所では,固定席をもたないフリーアドレスが採用されて いる。営業員やシステムエンジニアなど,テレワークを行っている社員はモバイラ と呼ばれ,モバイルPCとUSBデータ通信端末が貸与されている。モバイラは,tk 暇や長期出張などの場合を除き,週1時間以上Q社事業所に出社し,モバイルPC を社内LANに接続することが義務付けられている。 Q社では,モバイルPCを含むIT機器全てを情報システム部(以下,IT部という) が管理している。Q社には,IT全般に関する問合せ窓口としてIT部内にITヘルプ デスクが設けられており,電話,電子メール(以下,メールという),チャットでサ ポートを行っている。ITヘルプデスクは情報セキュリティに関する問合せも受け付 けている。 [モバイラのテレワーク環境〕 Q社では,モバイラの顧客先などでのテレワークを支援するために,表1に示すク ラウドコンピューティングで実現されたサービス(以下,。クラウドサービスという) を利用させている。クラウドサービス利用に関するQ社のセキュリティガイドライ ンを図1に示す。 表1 0Q社が利用させているクラウドサービス 機能概要 メール,SPAMフィルタ及びマルウェア対策の機能を提供する。 、|利用者認証付きのHTTPプロキシ機能,URLフィルタ機能,及び HTTPリクエストヘッダの文字列検査によるフィルタ(WE,RHフ ye Jィルタという)機能を提供する。RHフィルタ機能では,正規表現を 使用することができる。利用者認証の有効期間は24時間である。 N社コラボレーション|ファイル共有,掲示板,チャットなどの機能を提供する。各利用者に ツールQE,Nコラ|5Gバイトのファイル保管領域が割り当てられている。利用者がきめ ボという)細かなアクセス制御を設定可能である。 顧客企業情報管理,案件情報管理などの機能を提供する。 1.ユーザインタフェース上で無操作状態が5分以上続いた場合は,自動的にログオフされるよ う設定する。 2.利用者認証が連続して3回失敗した場合は,アカウントがロックされるよう設定する。 3.Q社貸与のモバイルPC及び社内LANからの,HTTP及びHTTP over TLS(LAF,HTTPSと いう)によるアクセスだけを許可するよう設定する。 図1クラウドサービス利用に関するQ社のセキュリティガイドライン(抜粋) Q社のモバイルPCには,マルウェア対策ソフト(以下,AMという)やパーソナ ルファイアウォール(以下,PFWという),オフィイスソフトウェアなどのQ社が利 用を認めたソフトウェア(以下,標準ソフトという)がインストールされている。 Q社内には,AM管理サーバがあり,社内LANだけからアクセス可能である。モ バイルPCは,社内LAN接続時に,AMのログをAM管理サーバにアップロードす De Q社のモバイルPCの概要を表2に,Q社のモバイルPCに導入されているPFW の概要を図2に示す。 表2 Q社のモバイルPCの概要 利用者D利用者は,ローカルユーザの利用者ID及び8桁以上のパスワードを使用す る。各利用者IDには当該モバイルPCのOSの管理者権限が与えられてい る。 プロキシプロキシ自動設定機能によって,インターネット上のWebサイトへのアクセ スは自動的に]プロキシを利用するよう設定されている。 可搬記憶媒体可搬記憶媒体を利用する場合,媒体上のデータが自動的に暗号化される。 ハードディスク|ハードディスク全体が暗号化されている。パワーオン時には,OS起動前にパ 暗号化スワードの入力を求めるプログラムが立ち上がり,認証を行う。認証が成功 FHL,ハードディスクへの書込み時の暗号化と読出し時の復号を透過的に 行うようになり,FOB OSを起動する。0Sからは,ハードディスク内にデ ータが平文で格納されているかのようにアクセスできる。 AMファイルの書込み時,読出し時及び実行時にパターンマッチングによるマル ウェアスキャンを行う。マルウェアの検知時には,ポップアップを表示し, マルウェア名と対処内容(検知だけ,隔離,駆除済み)を表示するととも に,ログに記録する。マルウェア定義ファイルは,インターネット上の専用 サイト(以下,AMサイトという)から自動的にダウンロードされ,更新さ れる。 脆弱性修正プロageインターネット上のベンダサイトから自動的にダウンロ グラム(UE,|「『され,適用される。 修正パッチとい う) ・次の通信だけを許可する。 -]プロキシを介したHTTP通信及びHTTPS通信 -PFW管理サーバ,AM管理サーバ及びAMサイトへの通信 -インターネット上のベンダサイトへのOSの修正パッチダウンロード用の通信 -DHCP通信,DNS通信及びNTP通信 ・次のログを記録し,モバイルPCが社内LANに接続されたときに,Q社内に設置されている PFW管理サーバにアップロードする。 -モバイルEC外との許可された通信の場合,通信したプロセスの実行ファイル名,通信先TP アドレス,通信先ポート番号,自ポート番号及び通信開始時刻 -モバイルPC外への許可されていない通信の場合,通信を開始したプロセスの実行ファイル 名,通信先IPアドレス,通信先ポート番号,自ポート番号及び通信開始時刻(アラートを PC画面上にも表示する。) -モバイルFC外からの許可されていない通信の場合,通信元IPアドレス,通信元ポート番 号,通信先ポート番号及び通信開始時刻 ・上記通信許可及びログの記録に関する設定を含むポリシは,PFW管理サーバ上にあり,それが 更新された後,初めてモバイルPCが社内LANに接続されたときに,ダウンロードされ,適用 される。 図2 Q社のモバイルPCに導入されているPFWの概要 Q社には,モバイルPCのバックアップを自動的に取得する仕組みはない。そのた め,必要なファイルはNコラボに保管しておくことが推奨されている。 [マルウェアの検知 Q社では,マルウェア検知時の対応手順を,図3のとおり定めている。 1.マルウェア定義ファイルを最新にした後,PCをネットワークから切り離す。 2.当該PC上でAMのフルスキャンを実行する。 3.フルスキャンでマルウェアが検知された場合,ITヘルプデスクに報告し,判断を仰ぐ。検知 されなかった場合,継続利用してよい。 図3マルウェア検知時の対応手順 2月1日,名古屋事業所のBさんからITヘルプデスクに“モバイルPCで繰り返 しマルウェアが検知される”との連絡が入り,IT部の情報セキュリティ担当者であ るCさんが対応した。Mik,その時のBさんとCさんの会話である。 Bさん:私のモバイルPCで,先週1週間に3回も同じマルウェアMが検知されま した。毎回“駆除済み”と表示されるのですが,駆除できていないのでし まうか。 Cさん:マルウェア検知時の対応手順に従ってAMのフルスキャンをしましたか。 Bさん:はい。もちろんです。3回とも実施しましたが,何も検知されませんでした。 Cさん:間題ないと思いますが,念のためIT部で調査します。モバイルPCのホス ト名と最後に社内LANに接続した日を教えてください。 Bさん:ホスト名はPC01です。FAS,社内LANに接続しています。 [IT部による調査 CさんがAM管理サーバのマルウェア検知ログを調べたところ,PC01ではマルウ ェアMが3回検知され,駆除されていた。他のマルウェアは検知されていなかった。 次に,CさんはPFW管理サーバで,マルウェア検知と同じ時間帯の,PCO1の PFWのログを確認した。PFWのログには,OS標準のWebブラウザ(以下,標準プ ラウザという)のプロセスからの通信だけが記録されていた。 Cさんが,マルウェア検知と同じ時間帯の」プロキシのログを調査したところ,次 BLEMBRP ok, ・マルウェア検知の直前に3回とも同じURLにアクセスし,同じ長さのコンテンツ がダウンロードされていた。 ・当該URLへのHTTP通信は,HTTPリクエストヘッダのUser-Agent(以下,UA という)が標準プラウザとは異なつっていた。 ・HTTPリクエストヘッダには,UAとHostだけが設定されていた。 該当するログは表3のとおりである。 ー18一 表3」プロキシの該当ログ 2016-01-25 xx.xx.13.1 user01|GET|http://yy.yyyy.yy/?vl 200 218783|DL2 09:13:29+0900=(省略) 2016-01-27 10.10.2.101|user01|GET|http:/yyyyjyyyy/Zv1 200 218783|DL2 09:23:34+0900=(省略) 2016-01-28 XXが18.1 user01|GET|http://yy.yyyy.yy/?vl 200 218783|DL2 09:12:27+0900=(省略) Time:処理終了時刻,CIP:クライアントIPアドレス,User:認証利用者ID,RM:HTTPリクエストメソッド SC:HTTPステータスコード,CCL:クライアントからのリクエストのコンテンツ長 SCL:サーバからのレスポンスのコンテンツ長,Ref:Referer 注記1“user01′はBさんの認証利用者IDを示す。 注記2“xx.xx.13.1”はUSBデータ通信端末利用時のIPアドレスを,“10.10.2.101"はQ HO IPアドレスを, "yyyyyyyyはC&CサーバのIPアドレスを示す。 Cさんは,マルウェアMをダウンロードする未知のマルウェアが,UAをDL2に 設定してC&Cサーバと通信していると考えた。]」プロキシのログからVAがDL2の 通信を検索したところ,次のことが分かった。 ・アクセス先URLは異なるものの,PCOは,1月25日以降ほぼ毎日UAがDL2の 通信を行っていた。 ・他にPC02てPC04の3台のモバイルPC AS,UAがDL2の通信を行っていた。 ・調査日当日もPC01からUAがDL2の通信があり,“200 OK”が返っていた。 ・①当該アクセス先URLに,Cさんに貸与されているPCの標準ブラウザからアク セスしたところ,"404 Not Found"が返ってきた。 Cさんは,これらのログの調査から,BさんのモバイルPCでマルウェアの検知・ 駆除が繰り返される事象は,未知のマルウェアが原因だと結論付けた。 Cさんは,②当該マルウェアによるモバイルPCからC&Cサーバへの通信をブロ ックする必要があることと,PCOについて専門業者による詳細な調査の必要がある ことをIT部D部長に説明し,調査依頼の承認を得た。 Cさんは,C&Cサーバへの通信のブロックを担当者に依頼した。次に,Cさんは, PCO1~PC04について,利用者に連絡を取り,IT部への送付を依頼した。Bさんを 含む各利用者は,当該モバイルPCをIT部に送付した。 [専門業者による調査 Cさんは,PCO1の調査をセキュリティ専門業者のX社に依頼した。X社による調 査結果は図4のとおりであった。 ・PC01の一時ディレクトリに不審なファイル5個と削除済みの不審なファイル13個があった。 ・不審なファイル5個のうち,2個はマルウェア本体,他の3個はマルウェアが利用する一時フ アイルであった。 ・削除済みの不審なファイル13個のうち,少なくとも4個は実行可能コードを含んでおり,マ ルウェアの一部であった。また,他の3個は先頭部分に圧縮ファイルを示す文字列が含まれて いたが,ファイルが不完全であったので展開できなかった。残りの6個は詳細が判明しなかっ TEs -活動している未知のマルウェアのプロセスを解析した結果,その実行ファイルは標準ブラウザ であった。標準ブラウザに対し,[a|インジェクション攻撃が行われ,不正なコードが 呼び出されて実行されていた。この不正なコードを含むファイルは,システムディレクトリに あった。 ・当該マルウェアは,改ざんされたバナー広告の表示によって感染が起きるマルウェアの亜種で あった。 図4 X社による調査結果(抜粋) [侵入経路と被害状況の調査 X社の報告を受け,Cさんはマルウェアの侵入経路及び外部への情報漏えいの有無 を調査した。侵入経路については,WebサイトWからマルウェアをダウンロードし ていたことが判明した。WebサイトWで表示していたバナー広告が改ざんされてお り,当該バナー広告を表示するときに利用するビューア(以下,ビューアVという) の脆弱性を利用して,自動的にダウンローダを導入・実行する攻撃コードが含まれ ていた。いわゆる| b|ダウンロード攻撃であった。ビューアYVは以前に業務 上必要があったので標準ソフトとして導入されていたが,現在では必要性はなくな っていた。ピビューアVの脆弱性は度々報告されていたが,Q社では標準ソフトの脆 弱性を管理しておらず,修正パッチの適用も強制していなかった。 PC02てPC04も,Bさんと同様に利用者がWebサイトWにアクセスしたことによ って感染していた。 外部への情報漏えいの有無については,各種ログやハードディスクに残されてい たファイルの痕跡からは,判断できなかった。PC01てPC04のうち,PCO01だけは, お客様プロジェクト関連情報(以下,F情報という)を含むファイルがハードディ スク上に複数保管されており,いずれも圧縮状態で200kバイト以上であった。一方, Jプロキシのログは,PCO1から外部に送信されたHTTP通信のCCLが,全て2kバ イト未満であることを示していた。これらから,Cさんは,外部への情報の漏え いはないと結論付け,調査結果をD部長に報告した。 次は,調査結果についてのCさんとD部長の会話である。 D部長:この分析結果からT情報の漏えいがないと判断するのは無理があります。 Cさん:なぜですか。 D部長KF,PCOLについてですが,マルウェアがPl情報の入ったファイルを して送信した可能性があります。また,PCO1のハードディスク ではなく,|d|]や[|e|]に格納されていたTI情報が初取され た可能性もあります。 Cさん:確かにそうですね。再度調査します。 Cさんは,再度調査を行ったが,Pl情報漏えいの痕跡は発見できなかった。Cさ んはそのことをD部長に報告した。D部長は調査結果を了承した。 Cさんはこの調査結果を,Bさん及びPCO2~PC04の利用者に伝えた。 〔委託元への報告 Bさんは,名古屋に本社がある流通業E社の業務システム開発プロジェクトに参 画している。E社との契約では,情報漏えいなどのセキュリティインシデント発生時 には遅滞なくE社に報告することが定められている。E社では,業務システムのプ ログラム開発及びテストには専用のPCを貸与している。Bさんは,設計書を含む文 書作成はPCO01で行いプログラム開発及びテストは社から貸与されたPCで行っ CWE IT部での調査結果を基に,今回の件ではPT情報の漏えいはなかったというのがQ 社の見解であるが,営業部,IT部,法務部及び名古屋事業所のF部長が協議した結 果,IT部の調査結果を基にE社に報告することにした。 3月28日,F部長がE社に報告したところ,EHO G部長から非常に厳しい叱責 を受けた。G部長の見解は図5のとおりである。 ー21一 ・マルウェア感染は報告すべきセキュリティインシデントである。 ・業務システムの設計書が外部に漏れると,事業上多大な影響がある。 ・発生後すぐにセキュリティインシデント報告をすべきであった。 ・Q社内の調査だけで情報漏えいはなかったと結論付けているが信用できない。 ・BさんのモバイルPCから社に提出又は送信した文書ファイルによって,E社のシステムが マルウェアに感染した可能性もある。 図5 E社G部長の見解(抜粋) F部長は,営業部,IT部及び法務部と相談し,図6の対応方針をまとめ,早急に 対応を進めた。 ・次の追加調査をX社に依頼する。 -情報漏えいの痕跡 -Bさんから社宛てに送信したメールの添付ファイル -Bさんが社に提出又は送信した文書ファイル ・今回のマルウェア感染に対する再発防止策を策定する。 ・上記の調査結果と再発防止策を部長からE社G部長に説明する。 図6対応方針(抜粋) X社の追加調査の結果は,Q社内での調査と同様,情報漏えいの痕跡は認められな いというものであった。また,BさんからE社宛てに送信したメールの添付ファイ ル及びE社に提出又は送信した文書ファイルには,不審なコードは含まれていなか ったとの報告であった。BE [再発防止策の策定] 今回のマルウェア感染に対する再発防止策を,IT部が中心に策定することとなっ た。Cさんは,調査で判明した事実を基に,他のIT部のメンバとともに課題を抽出 し,対策を検討した。その結果は表4のとおりである。 表4課題と対策 1(省略)標準ソフトの脆弱性管理を行い, 必要な修正パッチを適用する。 2|ビューアVを含む標準ソフトの| f ]が行わ|定期的に標準ソフトの[f| れていなかった。を行う。 3・マルウェアが検知されても,AMで駆除でき,(省略) AMのフルスキャンで他のマルウェアが検知され なければ,当該PCの継続利用を認めていた。 ・AMの検知状況を監視していなかった。 4(省略)未知のマルウェアに対する対策 (QE,未知マルウェア対策とい う)を行う。 Cさんは,課題と対策をD部長に報告した。D部長は,表4の項番1ご3の対策を 再発防止策とし,可能な対策から順次実施するとともに,項番4の対策を具体化す るよう指示した。 [未知マルウェア対策の検討〕 Cさんは,D部長の指示に従い,未知マルウェア対策の検討を始めた。次は,未知 マルウェア対策の検討についてのCさんとD部長の会話である。 Cさん:未知マルウェア対策として,図7の案を考えました。未知のマルウェエアを全 て検知するのは無理です。そのため,未知のマルウェアへの感染を前提と した対策も必要です。 [未知のマルウェアの検知を目的とした対策】 ・入口対策:Web閲覧やメールで入ってきたファイルをサンドボックスで実行し,振る舞いを 調べることによってマルウェアを検知する対策など ・出口対策:レビュテーションやアノマリ検知によって,C&C通信を発見する対策など 【未知のマルウェアへの感染を前提とした対策】 ・マルウェアに感染しても情報が漏えいしない対策(データの暗号化など) ・マルウェアに感染しても感染前の状態に戻せる対策(ブートイメージからの復元など) 図7未知マルウェア対策案(抜粋) D部長:我が社のモバイルPCではハードディスクの暗号化を行っていますが,マル ウェア感染時の情報漏えいを防げますか。 Cさん:残念ながら,③マルウェア感染による情報漏えい対策としては役に立ちませ ん。そうした情報漏えいを防ぐためにはDRMのような仕組みが必要になり, 取引先にも影響があります。 DWE::なるほど。ブートイメージからの復元というのはどのようなものですか。 Cさん:ブートイメージとはOSの起動に必要なファイルや標準ソフトなどをひとま とめにしたものです。これを読取り専用領域に保存し,起動時に読み込ま せることで,動作環境を復元します。実装方法として,モバイルPC上に読 取り専用領域を作成する方法と,図8のように,仮想端末上でゲストOSを 動かす,画面転送型の仮想デスクトップ環境(以下,VDIという)の二つが あります。これら二つの対策を我が社が利用した場合,表5で示すメリッ トとデメリットがあります。 VDIサーバ |ae—_ VDIー本 仮想端末ーープート ーーデーー||イメージ |ーー VDI 。[Fanos||外部ディスク VD!映末:仮想端末に接続する端末 注記破線は,ブートイメージを仮想端末にゲストOSとして読み込むことを示す。 M8 VDIのシステム構成 表5メリットとデメリット(抜粋) 1|モバイルPC上|・実装が容易・④再起動時に一部のセキュリティ に読取り専用領|.オフラインでも使える。対策が初期化される。 域を作成・利用者ごとの個別の設定が困難 ・運用負荷が高い。 2|vnI・運用負荷が低い。・既存のAM利用時に問題が発生す ・利用者ごとの個別の設定が|る。 容易・設備費用が高い。 D部長:表5によるとVDIが良さそうですが,デメリットを解消する方法はありま すか。 Cさん:AMに関しては,VDIに対応した仮想アプライアンスやゲートウェイ型のも のが利用できるクラウドサービスを検討します。 D部長:VDI端末としてモバイルPCは使えるのですか。 Cさん:はい。モバイルPCを使ってUSBメモリからVDI専用0Sを起動する方法 があります。 D部長:VDI端末には,どのような要件が必要ですか。 Cさん:要件は,次の四つです。 要件1:VDIサーバにログインできる。 要件2:仮想端末との間では,画面及びキーボード・マウスの操作データだ けの送受信を許可する。 要件3:マルウェア感染を防ぐ仕組みがある。 要件4:要件1て要件3を満たすのに必要な通信だけを許可する。 D部長:要件3が満たせずに,VDI端末がマルウェアに感染しても,要件2が満たさ れていればぱば,仮想端末には影響びないですよね。 Cさん:いいえ。ぐ⑥要件2が満たされても,VDI端玉上のマルウェアによる仮想端末 からの情報の補取は可能です。 DBR::そうですかが。 Cさん:そういった情報の寅取を防ぐためには,VDI端末の徹底的な要塞化が必要で す。VDI端末に汎用OSを使う場合,VDI端末の保護のための仕組みが必要 になります。一方,VDI専用0S HAT SBA,IU BAO USBメモ リにVDI専用0Sを入れておきます。VDI端末のハードディスクの中身は全 て消去し,USBメモリからだけブートできるようにします。ブートすると VDIに接続するためのソフトウェアが自動的に起動します。 D部長:なるほど。それでは,その案をベースに,VDIの実装案と移行計画をまとめ て提出してください。その際には,既存のガイドラインへの影響なども考 慮に入れてください。 Cさんは,VDIの実装案,クラウドサービス利用に関するQ社のセキュリティ ー25— ガイドラインの変更案,及び移行計画をD部長に提出した。D部長はこれを承認し, 関係各部と調整して年次計画に組み込んだ。 F部長はこれらの結果を受けて,X社による追加調査の結果,再発防止策及び未知 マルウェア対策の計画をE社G部長に説明し,理解を得た。