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

共通の文章

協力会社とのファイルの受渡しに関する次の記述を読んで,設問1一5に答えよ。 U社は,従業員10,000名の半導体製造業であり,国内に工場を置いている。U tt Clk,幾つかの工程を国内の40社の協力会社に委託しており,生産計画や設計書類 のファイルを協力会社との間で受け渡す必要がある。ファイルの受渡し件数は,協 力会社によって異なるが,1日当たり1件から10件である。U社では,生産管理課 が協力会社とのファイルの受渡しを担当している。ファイルの受渡しには,Webベー スのファイル交換システム(以下,Dシステムという)を使用している。Dシステム は,HTTPサーバ及びU社が開発したWebアプリケーションプログラム(以下,U アプリという)から成る。Dシステムではは受発注に関するファイルは取り扱っていな い。 図1は,Dシステムに関係する機器の全体構成である。 Co RRR) 2B UPC FW:ファイアウォール 図1 Dシステムに関係する機器の全体構成 U社の生産管理課及び協力会社に設置したファイル受渡し用PCからDシステムま でのアクセスは,HTTPSで行われている。U社ネットワーク内からDシステムにア クセスできる端末は,FWの設定によって,生産管理課に設置したファイル受渡し用 PCだけに制限している。 Dシステムのアカウントは,協力会社の拠点ごとに一つ,U社が発行している。D システムの利用者認証は,利用者IDとパスワードによって行われている。 ーゥーー [セキュリティインシデントの発生〕 ある日,Dシステムのトップページが改ざんされるというセキュリティインシデン トが発生した。調査したところ,HTTPサーバの既知の騰弱性を悪用した攻撃によっ て改ざんされたと分かり,脆弱性修正プログラムの適用などをしてから復旧した。 セキュリティインシデントの調査の過程で,HTTPサーバのアクセスログから,協 力会社P社に発行したアカウントを用いて海外のIPアドレスからアクセスした履歴 が見つかった。このアクセスは,Dシステムの利用規約や法令に違反しているおそれ があるので,P社に問い合わせたところ,P社の従業員の1人が海外出張先からアク セスしていたことが分かった。 Dシステムの利用規約では,ファイル受渡し用PCには,各協力会社の社内への設 置,並びに盗難対策.マルウェア対策及びファイルの不正持出し対策を求めている。 また,Dシステムには,ファイル受渡し用PCからだけアクセスすることを求めてい る。しかし,U社ではいずれの遵守状況も確認していなかった。 こういった利用規約違反への対策として,海外からのアクセスをFVWで禁止した。 さらに,協力会社以外からのアクセスを検知するために,SIEM(Security Information and Event Management)を導入した。 〔Dシステムの脆弱性診断 U社は,ほかにもDシステムに対策が必要な脆弱性がないかどうかを確認するた めに,脆弱性診断をセキュリティ専門会社であるN社に依頼した。 診断の結果,クロスサイトスクリプティング(以下,XSSという)脆弱性などが発 見された。XSS脆弱性が発見された箇所を,図2に示す。 『 ー3一 URL URL ファイル備考の入力ファイル備考の入力 フォルダ:協力会社A>生産計画フォルズダ:協力会社A>生産計画 ファイル:部品10293.pdfファイル:部品10293.pdf 備考:|部品10293の生産計画です。完成した部備考:部品10293の生産計画です。完成した部 品の納品場所は参考URLしのとおりです。品の納品場所は参考URLのとおりです。 参考URLあり:参考URL:Ittp:/www.u-shaco.jp/map001.html S*URL:ittp7wyurshacojpmap001html||上記の本人裕でアップロードしますか。 内を確認するアップロードする 画面A備考などの入力画面画面B入力後に遷移する確認画面 注記1矢印は画面Aの入力欄に適切な値を入力してボタンがクリックされたときの居移を示す。 注記2画面Bの下線は,リンクであることを示している。 図2 XSS脆弱性が発見された箇所 N社の,XSS脆弱性についての報告を図3に示す。 (1)XSS脆弱性の診断は,URLをWebブラウザのアドレスバーに入力し,HTTPレスポンス及び 表示される画面の内容を確認することによって行った。 (2)まず,図2の画面Aと画面Bの診断のために,診断用URL1と診断用URL2の二つを入力し た。診断用URL1を図4,診断用URL1を入力した時に得られたサーバからのHTTPレスポン スのボディ部を図5,診断用URL2を図6,診断用URL2を入力した時に得られたサーバから のHTTPレスポンスのボディ部を図7に示す。 (3)図5から,descriptionパラメタの値を画面Bの備考に出力する際には,エスケーブプ処理が正 しく行われており,XSS脆弱性は認められない。 (4)診断用URL2を入力した時に表示された画面B上で,参考URLのリンクをクリックすると, “XSS!”という内容のダイアログボックスが表示された。 (5)上記(4)と,図7から,refURLパラメタの値を画面Bの参考URLのリンクとして出力する際 の処理に問題があり,XSS脆弱性が存在すると認められる。 (6)上記(5)で示した脆弱性の原因は,retURLパラメタの出力部において,プログラミングに関す る次の二つの誤りのうちのどちらかによるものと想定される。 -XSSを防ぐための処理を一切していない。 -XSSを防ぐための基本的な処理はしているが,HTMLタグの属性値の出力時に必要な 処理が行われていない。 (7)RIL,いずれの誤りなのかを調べるために,図8に示す診断用URL3を入力した。その時に 得られたサーバからのHTTPレスポンスのボディ部が図CHS, 3 XSS脆弱性の報告(抜粋) ca 4= https://dsys.u-sha.co.jp/submitdescription?fi leID=001023&description=<script>alert(’XS S!’)</script>&checkbox=on&refURL=ht tp%3A%2F%2Fwww.u-sha.co.jp/ 図4診断用URL1 (省略) (省略) 参考URL:<a href="http://www.u-sha.co.jp/”>http://www.u-sha.co.jp/</a> (省略) 図5診断用URL1を入力した時のHTTPレスポンスのボディ部 https://dsys.u-sha.co.jp/submitdescription?fi leID=991923&description=test2&checkbox=on arefuRL-[<| 図6診断用URL2 (省略) 備考:test2<br> (省略) 参考URL:<a href=”wy</a> (省略) 図7診断用URL2を入力した時のHTTPレスポンスのボディ部 https://dsys.u-sha,co.jp/submitdescription?fi leID=001023&descr iption=test3&checkbox=on &refURL="%20onmouseover=alert(’XSS!’)%20foo=” B48診断用URL3 (省略) 備考:test3<br> (省略) 参考URL:<a href="&quot;onmouseover=alert('XSSI')foo=&quot;”>&quot; onmouseover=alert('XSSI')foo=&quot;</a> (省略) 図9診断用URL3を入力した時のHTTPレスポンスのボディ部 ーー5ーー (Dシステムの脆弱性対策] XSS脆弱性の報告を受けたU社は,N社の支援を受けて,DシステムのXSS脆弱 性対策を進めることにした。支援を担当した情報処理安全確保支援士(登録セキス べぺ)であるR氏は,二つの対策を提案した。 ーつ目の対策は,①図3で特定されたXSS脆弱性を解消するためのUアプリの改 修である。 =THORS,“Content-Security-Policy:script-src'self';”というヘッダフィール ドを,HTTPレスポンスのヘッダに追加することによって,Webブラウザに対して② 指定したスクリプトファイルの実行だけを許可するというものである。この対策は, ーフ目の対策に比べて短期間で実施可能であるが,Dシステムが用いている正規のス クリプトが意図したとおりに動作するように,③実行が制限されてしまうスクリプ トの有無を確認し,もしあれば,当該箇所の呼出し方法を変更する必要がある。 一部の古いWebブラウザはContent-Security-Policyに対応していないので,万全の 対策のためには,二つの対策を両方実施することが必要である。 U社は,R氏の提案どおり,Content-Security-Policyを速やかに追加するとともに, Uアプリの改修計画の策定を開始した。 (DシステムのSaaSへの移行の検討] U社の情報システム部のYさんがUアプリの改修を計画していたところ,将来に わたりU社でけアプリのメンテナンスを続けるよりもSaaSに移行する方が機能面で もセキュリティ対策の面でもよいのではないかという意見が出た。 そこで,Yさんは,Uアプリのメンテナンス継続とSaaSへの移行のメリットとデ メリットを比較した。比較の結果,表1に概要を示すG社提供のSaaS(UF,GY ービスという)に移行する方が,Uアプリのメンテナンスを継続するよりもメリット が多そうなので,更に詳細に検討することにした。 ss Ps 表1 Gサービスの概要 基本機能・利用者は,Webブラウザでアクセスする。 ・Gサービス上のストレージにファイルをアップロードしたり,ローカルのストレ ージにダウンロードしたりできる。 ・アップロードしたファイルは,複数階層にわたるフォルダで管理される。利用者 は,アクセス権に従ってフォルダを作成することができる。 ・ファイル及びフォルダに対して,利用者ごとにアクセス権を設定できる。 契約に伴う|・契約で定められた容量が割り当てられる。 制限・ほかの契約者に割り当てられた領域には,アクセスできない。 ・契約では発行できるアカウント数の上限が定められている。 Yさんは,Gサービスへの移行について,Dシステムの利用規約の継続を前提とし て,次の項目を検討することにした。 項目1:必要なセキュリティ対策のGサービスでの実現可否 項目2:SIEMとの連携 GHA 1 OB) Yさんは,項目1について検討した。表2は,その検討結果である。 表2項目1の検討結果 必要なセキュリティ対策Gサービスでの実現可否 協力会社以外からのアクセス禁|Gサービスで,送信元IPアドレスの制限を行うことができな ik WO CH Webアプリケーションプログラ|G社が実施するので可 ムの脆弱性への対応 サーバOS及びHTTPサーバへ|G社が実施するので可 の脆弱性修正プログラムの適用 |ファイルをGサービス上のスト|Gサービスの機能として,自動的に暗号化され,暗号鍵はG社 Iレージに保存するときの暗号化|が管理するので可 ファイルの完全削除ファイルを削除しても,Gサービス上のストレージに情報が残 る可能性があるので否 災害時の業務継続ファイルや管理情報が,日本国内とF国の両方のデータセンタ に保存されており,片方が災害に中ってもデータの消失とサ ービスの停止を防ぐことができるので可 次は,検討結果に関するYさんとU社のCSIRTリーダであるさんの会話である。 —vr i Yさん:表2のとおり,セキュリティ対策の大部分はGサービスで実現できますが, Gサービスが信頼できるかどうかの見極めが必要です。 TEA:そのとおりだね。例えば,クラウドサービスのための| q|]の実践の 規範であるISO/IEC 27017に基づく認証や,Dシステムとは直接関係がない が,パブリッククラウドにおける| e|の実践の規範であるISOMEC 27018に基づく認証を取得しているサービスであれば信頼してよいのではな いかな。 Yさん:Gサービスは,ISOMEC 27017に基づく認証を取得しているので,信頼でき そうですね。 Tさん:そうだね。ところで,F国では安全保障上の要請があれば,F国内に保存さ れているデータを,F国政府に強制的に提出させる国内法が存在する。④G サービスを経由して協力会社との間で受け渡すファイルの内容を保護する という観点で,どのような措置が当社として取り得るか,考えてほしい。 Yさん:分かりました。 【項目2の検討〕 現行のDシステムでは,協力会社以外からのアクセスを検知するためにSIEMを利 用しているが,GサービスではSIEMの機能は提供していない。Yさんが調査した結 果,Gサービスに移行した場合でも,GサービスのAPIを利用すれば,表3に示すロ グをU社のSIEMへ取り込めることが分かった。 表3提供しているログ ログには,操作対象,実行された操作とともに,AM,時刻,実行した利用者D, アクセス元IPアドレス,及び結果(成功又は失敗)が記録される。 続いて,Yさんは,Gサービスが提供している,利用者IDとパスワードによる誰 証を利用した場合に,SIEMを利用してログから不正アクセスが検知できるかどうか ーa一 を検討した。表4は,Yさんが考えた,ログから不正アクセスを検知する方法である。 表4ログから不正アクセスを検知する方法(抜粋) OE ees Becca ee 2|少数のパスワードについて,利用者|一定時間当たりの同一TPアドレスからの異なる利 1|利用者IDを固定して,パスワード|一定時間当たりの| f|]の回数がしきい値を えたら,不正アクセスとして検知する。 表4を確認したTさんは,いずれの不正アクセスもゆっくりと実行された場合には 見逃すことがあることと,項番2については,⑤ほかの場合にも見逃すことがあるこ とを指摘した。さらに,不正アクセスを防ぐには,多要素認証を採用する方がよい ことと,多要素認証は,Gサービス単独では実現できないが,IDaaSとの連携で実現 できることを読明した。 [IDaaSとの連携による多要素認証の実現方式の検討] Yさんは,IDaaSとの連携による多要素認証の実現方式の検討を開始した。幾つか のIDaaSを検討した結果,国内の互いに地理的に離れた複数のデータセンタで運用さ れているKサービスとの連携による実現が最適であると考えた。Kサービスでは, 様々な認証方式を選択できるが,Yさんは,Gサービスを利用した新たなファイル交 換システム(以下,Eシステムという)には,FIDO認証が最もふさわしいと考え, FIDO認証器として何を選択するべきか,検討を開始した。まず,Kサービスで利用 できるFIDO認証器の仕組みについて調査し,表5にまとめた。 ー9一 表5 FIDO認証器の仕組み 認証器Webブラウザと|認証器使用時の利用者確|複数利用者による認|MA” の通信方法認(User Verification)証器の共用 スマートフォ|Bluetooth経由スマートフォンに組み込|できない限定され シンまれた生体認証装置によない る生体認証 USB接続外部|USBポート経由なしできない限定され 認証器ない OS内蔵の生|OS内部処理OSに内蔵された生体認|OSの利用者ID間で|限定され 体認証機能証機能による生体認証可能る 注りKサービスにアクセスするPCL,認証器の組合せ 認証器としてスマートフォンを利用した場合の利用者認証の流れは図10のとおり であった。 en(KY—-KAIKEATT VY)<ICPAP HEE認証サーバ 認証器ge Webブラウザ«KKサービスの (1)利用者ID IDcの選択 乱数c<^の生成 (3)利用者ID,IDc,ドメイン,(⑫)IDc,ドメイン,乱数c^ H(オリジンb||乱数c^) 生体認証による利用者確認 (④)IDc,H(ドメイン),署名M 5)IDc,H(ドメイン),オリジンb, 署名M オリジンbがKサービスのもの であることの確認| 5)の正当性確認,署名Mの検証 IDc:認証器の登録時に,利用者IDとドメインの組みに対して,認証器ごとに発行するD H(A):Aのハッシュ値 A||B:AとBを連結 オリジンb:WebブラウザがアクセスしているWebサイトのオリジン 署名M:H(ドメイン),H(オリジンbb||乱数c^)に対するディジタル署名 10利用者認証の流れ Yさんは,10中の(3て(5)のメッセージの生成にオリジンbが使われていること についてTさんにその目的を尋ねた。Tさんは,攻撃者が,|g|するための 特別ながサーバをインターネット上に用意し,何らかの方法で被害者をそのサーバに 誘導し,認証情報を不正に入手して悪用するという攻撃を防御するためだと答えた。 続いてYさんは,Eシステムにおいて,それぞれの認証器を使用した場合を想定 し,認証器の取扱いを表6に,運用上のリスクと対策を表7にまとめた。 表6認証器の取扱い 認証器|Kサービスにおける|Eシステムにおける認証器|Eシステムにおける認証器 取扱いの所有者の配布方法 スマートフ|供給せず,要件を提|各協力会社又は利用者個人|協力会社によって異なる。 ォン示している。 USB接続|専用機器を契約者だ|U社の一括購入となるの|U社から必要個数を各協力 外部認証器|けに販売している。|で,U社会社に配布する。 OS内蔵の|供給せず,要件を提|各協力会社ファイル受渡し用PCが認 生体認証機|示している。証器を兼ねるので,認証器 能の別途配布は不要である。 表7運用上のリスクと対策(抜粋) 認証器の紛失・盗難時のリスクと対策退職時のリスクと対策 マートマフ認証器の使用時に|nh|が必要な退職者による不正なアクセスを防ぐ ay OC,不正利用される可能性は低い。ために,個人所有のスマートフォン を利用していた場合も想定して,退 職時又は退職後直ちに,|j」| では,|」|する必要がある。 USB接続|第三者による不正利用を防ぐために,直|(省略) 外部認証器|ちにする必要がある。 OS内蔵の|認証器の使用時に|hn|が必要な|休暇アカウントを悪用した不正アク 生体認証機OC,不正利用される可能性は低い。セスを防ぐために,ファイル受渡し 能用PCにログインするためのアカウン トを忘れずに削除する必要がある。 注!Eシステムの利用者だった従業員が退職した場合のリスクと対策 Y SAIS,各認証器を比較し,次のようにまとめた。 ・Kサービスのアカウントに対して認証器を登録する際は,いずれの認証器でも,不 正がないように確認する必要があり,登録について大きな差はない。 ・USB接続外部認証器は,紛失・盗難に備えた体制を整えるのが難しいので,採用し ない。 ・スマートフォン及びOS内蔵の生体認証機能は,認証器として大きな差はないが, ⑥Dシステムで要求されていたセキュリティ要件を技術的に実現できるので,OS 内蔵の生体認証機能の方が望ましい。 上記からYさんは認証器としてOS内蔵の生体認証機能を採用することにした。| その後,Yさんは検討を続けDシステムをEシステムに移行する案をまとめた。 U社では,その案を承認し,Eシステムへの移行を開始した。

共通の文章

マルウェア感染への対処に関する次の記述を読んで,設問1ー4に答えよ。 A社は,従業員8.000名の化学素材会社であり,首都圏に本社,地方には六つの支 社がある。素材の研究開発に関して古くから産学官連携をリードしてきた。4A社は, VPNサーバ及び基幹システムを,ハウジング契約を結んでいるデータセンタ(UE, DCという)内に設置している。A社の電子メール(以下,。メールという)は以前, 基幹システム内に設置していたメールサーバを利用していたが,現在はクラウド上 のWebメールサービス(WE,Bサービスという)を利用している。Bサービスへの 移行に伴う通信量の増加によって,DCにある統合脅威管理(LAF,UTMという) の処理能力は,ひっ迫している。従業員は,会社から貸与されたPC(以下,業務PC という)を業務に必要なWebアクセスやメール送受信などに利用する。 本社では,働き方の多様性を確保するためにテレワークを推進してきた。テレワ ークでは,従業員が業務PCを自宅に持ち帰り,自宅のネットワークからVPNサー バを介して,基幹システムや利用者LANにあるリソースにアクセスできる。テレワ ークでは,Bサービスなどのインターネットへの接続においても,同様にVPNサー バを介する。 図1にA社のネットワーク構成を,表1にその構成要素の説明を示す。 ee ECL ; 図1 A社のネットワーク構成(概要) ー14一 表1構成要素の説明(概要) 構成要素 共有ファイルサーバ,人事システム,経理システムなどから構成されている。 テム VPNサー|従業員がテレワークに利用する。業務PCのVPNクライアントソフトウェアを起動 バすると,VPNサーバとの間にIPsecによる通信路が確立する。VPNサーバへの接続 の際に2要素認証を行う。 UTMインターネットとの接続境界に設置され,グローバルIPアドレスをもつ。次の機能 を備えており,そのうちファイアウォール(以下,FWという)機能とDS機能を 有効にしている。 FW機能:ステートフルパケットインスペクション型であり,送信元IPアドレス, 送信元ポート,宛先IPアドレス,宛先ポートを指定して通信をフィルタリングで きる。通信のログを取得する。 IDS機能:全てのインバウンド通信をチェックし,不審な通信を検知した場合は, システム管理者に通知する。 DNSシンクホール機能:DNSクエリをチェックし,危険リストに登録されている FQDNの場合は,正規の名前解決を行わずにA社があらかじめ用意したIPアドレ スを応答する。危険リストは,日次で自動更新される。 Al用者|従業員の業務PCやネットワークプリンタといったOA機器が設置されている。部 LANごとにセグメントを分けているが,本社と支社間も含めてセグメント間でアクセス 制限はしていない。 Bサービ|従業員ごとに払い出されたメールアドレス及びパスワードを入力すると利用でき スる。アクセス制限機能によって,アクセス元IPアドレスがUTMのグローバルIPア ドレスの場合だけアクセスが許可される。 [社外との情報共有 A社の研究部は,素材研究とその実用化に関する情報を共有する“化学研究開発コ ンソーシアム”という団体(以下,化学コンという)を運営している。化学コンに は,研究機関や大学,企業など40組織が会員として加盟している。化学コンでは, 月に1回,対面形式の連絡会議が開催され,会員の上位役職者が参加している。連絡 会議では,研究開発における機密性の高い議事も扱われる。開催案内などの機密性 のあまり高くない情報の共有はメールで行われるが,重要な情報は情報連携システ ムと呼ばれるSSHを用いたシステムで共有されている。 SA,情報連携システム用の連携端末を設置する必要がある。化学コンは,会 員に図2に示す連携端末設置ガイドライン(以下,ガイドラインという)を提示し, 遵守を求めている。 1.連携端末を設置し,別途定める要件を満たす機器,ソフトウェアを導入し,別途定める運用を FT Oe 2.連携端末かぬからインターネットにアクセスするときのグローバルIPアドレスを化学コンに伝える Sit 3.共有した秘密情報は,別途定める秘密情報管理規程に従って管理すること 4.連携端末に関して,セキュリティインシデント(以下,インシデントという)が発生した場合 は,化学コンと協力して解決すること 図2ガイドライン(抜粋) 情報連携システムの構成を図3に,情報連携の手順と会員間で共有するファイルを格 納する連携サーバの運用を図4に示す。 an De xt portー1,0 rr]--」 」ネットワー|研究部セグメント1 ーーーsmc Pee ーーーLE sw]| 1ーーニニーーーニーミ)) 情報連携システムaneーーーーニーニーニニーーニーニニーーニーニニーーニーニーニーニーニニニーニャニーかっビィ2ーーニニニニニニニニニーーart jac|| ||| 会員FW:会員の基幹FW L3SW:レイヤ3スイッチ 連携FW:連携サーバ用のFW 図3情報連携システムの構成 [情報連携の手順] ・A社の担当者は,共有したいファイルを連携サーバの共有フォルダに置く。連携サーバの共有 フォルダは研究部セグメントの業務PCから認証なしでアクセス可能になっている。 ・連携サーバ及び連携端末には,SSHアプリケーションプログラムが導入されている。3時間に 一度,自動的に連携端末から連携サーバにSSH通信を行い,認証に成功すると連携サーバの共 有フォルダにあるファイルを,連携端末の所定フォルダにコピーする。 ・会員の担当者は,随時,所定フォルダにあるファイルを連携端末上で閲覧する。 [連携サーバの運用] ・連携サーバはSSHによる連携端末へのファイルのコピーが行われるとログファイルにログを出 力する。ログファイルは日付を示す8桁の数字のファイル名で毎日生成され,60日間保存され る。61日以前に生成されたログファイルは,毎日0時に起動する連携サーバの日次バッチ処理 で自動削除される。 ・ログファイルに出力されるログ項目は,SSH接続ごとに,“接続日時,ABS,コピーファイ VE,コピー成功/失敗ステータス"である。 図4情報連携の手順と連携サーバの運用 連携サーバは,研究部が管理する連携FWを経由してインターネットに接続されて いる。連携FWでは,会員から伝えられたグローバルIPアドレス及び研究部セグメ ントから連携サーバヘへのアクセスだけを許可している。 〔テレワークの検討] 2月2日,首都圏を中心とする感染症の急激な流行に伴い,A社は本社に勤務する 従業員に対して,2月16日から原則,テレワークとする方針を決定した。また,よ り多くの従業員がテレワークに移行できるよう,テレワークWGを立ち上げた。テレ ワークWGには,情報システム部など関係する部の担当者が参加し,インフラ増強や ルール整備を検討する。A社では,公的機関が発行したテレワークセキュリティガイ ドラインを参考に,図5に示すテレワークセキュリティ規程を作成し,本社に適用し Toon 役割を次のとおり定める。複数の役割を兼務する場合もある。 経営者:組織のあるべき姿を検討し,テレワークセキュリティ全般を考え,必要なリソースを確 保する。 システム管理者:情報システムへの不正アクセス,マルウェア感染などのインシデント発生時の 対処のルールを定める。 テレワーク勤務者:定められたルールを遵守し,データを安全に扱う。 [詳細] 1.|。dik,テレワークの推進に必要な人材・資源を確保するために,必要な予算を割り aT, 2.|b|は,情報セキキュリティポリシに従い,セキュリティ維持に必要な技術的対策を講 じるとともに,定期的に実施状況を点検する。 3.|<|]は,社内システムに,強度の低いパスワードが用いられないように制限を掛け る。 4.|did,パスワードの使い回しを避け,12桁以上の長さで他人に推測されにくいもの を設定する。 5.システム管理者は,暗号化された通信路をテレワーク勤務者に提供する。その際,電子政府に おける調達の際にも参照される| 。 ]時号リストを参照し,暗号化には危殆化していな い暗号アルゴリズムを採用するものとする。 図5テレワークセキュリティ規程(抜粋) [ネットワーク構成の見直しの検討] テレワークWGでは,支社でもテレワークの準備が必要であるという意見が出た。 しかし,支社でのテレワークに本社と同様の方式を採用すると,UTMの処理能力を 超過することが予想された。そこで,テレワークWGは,新たなネットワーク(以 下,新NWという)の導入を検討することにした。図6に新NWの内容,図7に新 NWの構成を示す。 ・各支社に,新たにインターネット接続回線を敷設し,拠点FW及び拠点DMZを新設する。拠 点DMZ内に拠点VPNサーバを新設する。 ・テレワーク時,支社のテレワーク勤務者には,所属する支社の拠点VPNサーバに接続させ, 基幹システムや利用者LANにあるリソースにアクセスさせる。WA VPNサーバ接続時には, 本社と同様に2要素認証を行う。 ・テレワーク時のインターネットアクセスは,一度,拠点VPNサーバにアクセスさせ,DCを 経由させる。ただし,①Bサービスへのアクセスだけ,拠点VPNサーバから,DCを経由させ ずに支社に敷設したインターネット接続回線を経由させる。 図6新NWの内容 es し|HLAN| 1— ErリンH geal} —|。Lag ||拠点VPN|I 図7新NWの構成 テレワークWGは,新NWの導入に先立ち,ある支社で新NWをテストした。② その支社のテレワーク勤務者が,インターネットへはアクセスできたが,Bサービス に接続できないというトラブルが発生した。Bサービスの設定を変更することによっ てトラブルは解消でき,無事,テストが完了した。A社は新NWの導入を正式に決定 し,6月15日,各支社でもテレワークを開始した。 [インシデントの発生] 9月11日,情報システム部のシステム管理者であるCさんは,差出人が総務部の Dさんと表記されたメールを受信した。メールの文面に違和感を覚えたCさんが,B のためDさんに電話で確認したところ,“そのようなメールは送信していない"とい う回答だった。Cさんは,すぐさまA FLO CSIRTに報告した。報告を受けたCSIRT 所属のEさんは,調査を行い,Dさんの証言やBサービスの利用履歴などからDさ んのBサービスのアカウントが第三者に不正利用されている可能性が高いと判断し た。Eさんは,情報システム部のCさんに,Dさんのアカウントの無効化措置を依頼 した。その後,契約中のセキュリティベンダX社に所属する情報処理安全確保支援 士(登録セキスペ)OP氏の支援を受け,9月16日に図8に示す初期調査結果をま とめた。 [タイムライン] ・4月1日:情報システム部が新NWのテストでのトラブル解消のために,Bサービスの設定を変 更した。 ・7月9日:攻撃者が,何らかの方法で入手したDさんのアカウントを使って,インターネット からBサービスに不正ログインした。 ・7月14日:攻撃者は,Dさんのアカウントを使って研究部のFさん宛にマルウェアewを添付し たメールを送信した。Fさんがそのメールの添付ファイルを開いた結果,Fさんの業務PCがマ ルウェアgwに感染した。同日中に,攻撃者の遠隔操作によって同業務PCがマルウェアにも感 He Le, ・7月28日から9月11日:攻撃者はDさんのアカウントを使って,CXAREMAZOUERARMIC マルウェアJを添付したメールを断続的に送信した。 ・9月11日:Cじさんから報告を受け調査を開始した。 [攻撃者の活動の特徴] ・攻撃者は,メールの送信間隔を空けたり,マルウェアの拡散速度を遅くしたりしていた。感染 した業務PCからA社内の情報を不正に取得していた。 ・攻撃者は,メールの送信をDさんに知られないよう,マルウェアを添付したメールを送信済み ボックスから全て削除していた。 ・一部の業務PCでは,全てのイベントログが消去された痕跡があった。全てのイベントログが消 去された後,イベントログにイベントログの消去を示すログが記録されていた。 ・攻撃者がDさんのアカウントを使って送信したメールは,タイムラインに示したA社内宛のメ ールだけであり,社外宛のメールはなかった。 図8初期調査結果(概要) 同日,X社からマルウェアの解析結果が報告された。マルウェアg及びマルウェア のどちらにもA社を標的にしたと思われる識別文字列,A社固有のファイルパス, 並びにC&CサーバのIPアドレス及びFQDNのリストが埋め込まれていた。また, どちらもA社が導入しているマルウェア対策ソフトでは検出されなかった。報告さ れたマルウェアの特徴を表2に示す。 表2マルウェアの特徴 特徴 マルウ|PC又はサーバが感染すると,C&Cサーバと通信を確立し,攻撃者が遠隔操作できる cya|状態になる。このとき,イベントログにマルウェアgwの実行を示すログ(以下,an グという)が記録される。 マルウ|次の①て3)の機能をもつマルウェアである。PC又はサーバが感染すると,いずれか エア8の機能を,あらかじめ定められた確率でランダムに実行する。この実行は,1週間の 間隔を置いて繰り返され,遠隔操作機能の実行に成功すると,繰り返しの実行を停止 する。 (1)待機機能 何もしない。 (2)横展開機能 感染したPC又はサーバから到達可能なネットワーク内の機器をスキャンし,OSの ぜい 脆弱性がある機器を発見すると,自身に感染させる。また,アクセス可能な共有フ ォルダを発見すると,細工された文書ファイルを生成し,その共有フォルダに置 く。細工された文書ファイルを開いた機器はマルウェア8に感染する。 (3)遠隔操作機能 当該PC又はサーバ内に保存されているクレデンシャル情報を収集する。C&Cサー バと通信を確立し,収集した情報をC&Cサーバに送信する。このとき,イベント ログにマルウェア8の実行を示すログ(以下,8ログという)が記録される。以 後,当該PC又はサーバの起動中はC&Cサーバから攻撃者が遠隔操作できる状態 を維持する。 A社は重大なインシデントが発生したと判断し,社内規程に従い緊急対策本部(以 下,対策本部という)を設置した。 [インシデントへの対策の検討] このインシデントでは,DさんがBサービスに脆弱なパスワードを設定していたこ とに加えて,新NWの導入に際してのBサービスの設定変更も攻撃が成功してしま った要因であることが分かった。 対策本部長(以下,本部長という)は,初期調査結果及びマルウェアの特徴をメ ンバと共有し,優先すべき対策を表3のように整理した。 表3優先すべき対策(抜粋) 次は,対策本部会議での,本部長,対策本部メンバのGさん及びP氏の質疑であ る。 本部長:対策1については,どのように行うのか。 Gさん:マルウェアgwとマルウェア8にはC&CサーバのIPアドレスとFQDN OY ストが埋め込まれていました。そのIPアドレス,及びそのFQDNのDNSの 正引き結果のIPアドレスの二つを併せたIPアドレスのリスト(以下,TPリ ストという)を手作業で作成しておき,IPリストに登録されたIPアドレス への通信をUTMで拒否します。 PKR:その対策だけでは,③攻撃者が行う設定変更にとよって,すぐにマルウェアg やマルウェア8の通信を遮断できなくなることが考えられます。④そこで, UTMでの通信拒否に加えて,追加の暫定対策として,UTMのDNSシンク ホール機能の有効化を推奨します。 本部長:では,両方の対策を実施しよう。次に,対策2については,どのように行う のか。 Gさん:まず感染を確認するために,イベントログにゥwログ又は8ログが存在するか どうかをチェックする確認ツールを作成してA社内に配布し,従業員に実行 してもらいます。 PR:イベントログに|1|が存在するかどうかもチェックする必要がある と思います。さらに,確認ツールは暫定対策として有効ですが,全ての感 染を確認できるわけではありません。確認ツールを実行し,問題がない と判定されたPCやサーバであっても,その後,別のPCやサーバに感染を 拡大させることが考えられます。 本部長は,確認ツールとは別に,より高い精度でマルウェアoc及びマルウェア8』 ー21一 を検出し,駆除できるツール(以下,駆除ツールという)の開発をX社に委託する ことにした。P氏は,開発する駆除ツールは,ディジタルフォレンジックスの経験を 有する技術者だけが扱うことができるツールになることを説明した。 P氏は,対策本部会議の恒久対策に関する質疑の際に,将来的には連携サーバを DCのDMZに移設し,WE FWを廃止する検討をした方がよいとの意見を述べた。 その理由として,⑥⑧インターネットから連携サーバが攻撃を受けたときに,より迅 速な対応が可能であることを挙げた。 その後の対策本部会議の質疑の中で,連携サーバ自体が感染していなくても連携 サーバ経由で,会員にもマルウェア8の感染を拡大させている可能性が指摘された。 本部長は,EXAM,早急に連携サーバ経由の感染状況を確認し,感染拡大を防止す るよう指示した。 [連携サーバ経由の感染状況の確認と感染拡大防止〕 Eさんは,まず,連携サーバをネットワークから切り離し,ディスクイメージを保 全した。また,化学コンの運営責任者を通して,化学コンの全会員に連携端末を一 時的にネットワークから切り離してもらうように連絡し,全ての会員で対応が完了 したことを即日確認した。9月17日,さんは連携サーバの担当者にヒアリングを実 施した。ヒアリングの際に,連携サーバに存在するログファイルを担当者に確認し てもらったところ,最も古いものは7月19日に生成されたものであることが分かっ た。Eさんは,マルウェア8の感染を拡大させている可能性があることから,BAT も何らかの対処が必要であり,会員によってはPCやサーバで,駆除ツールを実行し なければいけないと考えた。また,駆除ツールが扱える技術者を多数確保すること は難しいので,全ての会員に対して一斉に対処をすることはできないと判断し,次Py の対処方針を定めた。 ・感染調査手順書を作成し,各会員の担当者に調査を依頼する。その調査結果から, 会員をるダループAとグループBに分ける。 グループA:感染の疑いが強く,より早期に対処が必要な会員 グループB:それ以外の会員 ・グループAの会員には,P氏と駆除ツールが扱える技術者が連携端末設置場所に赴 き,駆除ツールを用いて連携端末上のマルウェアJ』を駆除する。さらに,マルウ ー99一 ェア感染に伴う会員側の被害を確認し,その対処をA社が支援する。 ・グループAの全会員での駆除が完了した後に,グループBの会員に対して同様の 手順で駆除を含めた対応を行う。 [感染調査手順書のレビュー〕 Eさんは感染調査手順書案を作成し,P氏にレビューを依頼した。表4は感染調査 手順書案に記載した感染調査項目,図9はP氏からのレビュー回答である。 表4感染調査項目 調査結果 調査1|連携端末の対象期間!中のイベントログに,any,Bo グメは||が在するかどうか 注!対象期間:7月19日へ調査日当日 感染調査項目に関して次の見直しを行う必要がある。 指摘1:対象期間の開始日は,本来は,保存されている最も古いイベントログの日付にすべきだ が,せめて連携サーバに細工されたファイルが置かれていた可能性のある最も早い日付である |』|にする必要がある。 指摘2:マルウェア8の特徴を踏まえると,会員内での感染の広がりも考慮する必要がある。本 来は,会員の全てのPCを確認してもらうべきだが,せめて会員FWのログの確認は追加で依 頼する必要がある。 図9 P氏からのレビュー回答 EさんはP氏の指摘2に対する改善案として,表5に示す感染調査項目を追加し, 調査2の調査結果が“記録あり”"である場合もグループAと判定することにした。 表5追加した感染調査項目 調査結果 調査2|対象期間中の会員FWのログに,次に該当する送信元から 宛先への通信記録が存在するかどうか。 送信元:任意のIPアドレス記録なしり|グループB $=”SE FWでログが取得されていない場合や,一部ログが欠けている期間があっても,ログが 存在する範囲で通信記録がない場合は記録なしとする。 Eさんは,再びP氏のレビューを受けた。次は,再レビュー時のP REEさんの 会話である。 PKR :今回の感染調査の目的は,感染の疑いが強い会員を見つけることなので, 調査2の内容は良いと思います。提案なのですが,仮に今回の感染調査の結 果,大多数の会員がグループAと判定された場合,グループ分けの意義が薄 れてしまいます。グループAと判定された会員の中から,更に対処を優先す る会員を絞ってはどうでしょうか。 Eさん:対処を優先する会員をどのように絞ればよいのでしょうか。 P氏:の⑦連携端末からほかのPCやサーバへの感染拡大が明らかな会員に絞るので あれば,調査2に使う通信記録から絞ることができると思います。グループ Aと判定された会員企業であっても,この通信記録がなかった会員は,OM に行っている対応から考えて,感染を拡大させるリスクは相対的に低いと 考えることができます。 EさんはP氏の指摘や助言に従い感染調査手順書を修正し,会員に送付した。巧つ の会員がグループAと判定されたものの,どの会員にも深刻な被害は確認されなか った。A社はその後もインシデント対応を進め,社内の詳しい調査を経て,攻撃者の 活動は初期調査結果どおりだったことも確認した。対策1と対策2の暫定対策と恒久 対策を完了したA社は,対策本部を解散し,再発防止に向けた新たな取組の検討に 着手した。