第五回目の対談は、2018 年 8 月に日本監査研究学会の会長になられた日本大学商学部 教授 堀江正之 氏をお迎えしました。堀江氏は監査論を中心に、IT 監査、IT リスク マネジメント、及び、内部統制などの分野について長年研究をされてきました。本日は、新学会長としての抱負も含め、「サイバー攻撃リスクへの対応としてどう会社を守るべきか」をテーマに藤沼理事長とお話しいただきます。
近年、企業内の不正問題とともに、外部からの不正アクセスやメール詐称などによって企業の情報システムが攻撃され、多額の損失を被る事例が増えています。公認不正検査士は、企業の内部関係者のみならず外部からの不正攻撃に対しても、不正抑止・防止策の構築、また、不正の早期発見や不正調査に携わることが期待されています。特に、サイバー攻撃によってもたらされる情報システムのダウンや顧客情報の流失などの経済的損失は膨大になることが予想されるため、今後どのように IT 関連不正への対策を講じるべきかについて堀江氏にお伺いしたいと思います。
(聞き手:ACFE JAPAN 理事長 藤沼亜起)
金融庁 企業会計審議会 臨時委員、金融庁 契約監視委員、経済産業省 情報セキュリティガバナンス研究会 委員、日本内部統制研究学会 常務理事 等を歴任。
中央大学 商学部 卒。1974 年 公認会計士 登録。国際会計士連盟 (IFAC) 会長 (2000-2002)、日本公認会計士協会 会長 (2004-2007)、IFRS 財団 評議員会 (Trustees) 副議長などを歴任。
堀江先生の IT 監査や IT リスク マネジメントに関する研究について、簡単にご紹介いただけますでしょうか。
私は大学院生のころ、「監査公準」を研究テーマとしており、監査論は社会科学として成立するかどうかなどと生意気なことを考えていました。しかし、恩師の影響もあって、そのような考え方の正に対極にあるコンピュータの勉強を始めました。
監査の根源的な機能は、「大丈夫です、確かです」という保証 (お墨付きの付与) にあるとするのが通説です。ところが、本当に保証が必要なシステムに対して保証が付与されているかというとそうではありません。現実に、アメリカでは、放射線治療機器に組み込まれたプログラムのバグ (不具合) が原因で数名の患者が相次いで死亡する事故が起こっています。国内で言うと、公共料金等の算定が正確なのか、千代田区に住んでいる人の個人情報が区役所のシステムにより完全に保護されているのかなど、利用者に向けた保証の仕組みはありません。これらのようなシステムこそ、保証が求められていると思います。
このように、監査の根源的な機能と、技術としての IT といった、一見、関係がないように見える部分をいかに結びつけるかについて研究を進めています。最近では、AI (人工知能) やブロックチェーンなどの技術が監査の世界にいかなる影響を及ぼす可能性があるかに関心を持っています。
昨今、サイバー攻撃によるシステム ダウン、個人情報・知的財産や企業秘密等の情報漏洩、取引先を騙る金銭被害などが実害として多く報告されています。そして、2020 年の東京オリンピック開催により、日本のサイバー攻撃への対策が試されるとも報じられています。現状、どのようなサイバー攻撃が主流となってきていますか。
2020 年を見据え、国もサイバー対策の特別組織を編成し対応を始めています。今は爆弾投下よりサイバー テロの方がダメージは大きいと言われています。パニックを誘発するには、公共交通機関の麻痺や首都圏の全停電などが最も手っ取り早いためです。
これまで不正というと、組織の内部者の悪事という前提で考えていましたが、今後は会社や組織が被害者になるだけでなく加害者になってしまう状況も想定されます。サイバー攻撃の問題はいくつかの視点に分けて整理する必要があります。
まず 1 つ目は主体。これまでとの相違点は、委託先の社員や再委託先、取引先あるいは海外まで含まれていることです。全く関与のない海外の不特定者からの攻撃被害も実在します。
2 つ目は動機。かつてはシステムへの侵入を成功させることが目的で、愉快犯的でした。一時、特定の主義主張を展開するアノニマスというハッカーの国際的コミュニティが生まれ、実際に日本企業が被害を受けたことがありました。しかし今後は、経済的な利得とテロがサイバー攻撃の主流な動機となってくるでしょう。
3 つ目は誘因。最近は働き方改革により社外から社内 LAN にアクセスできる、ネットワークのオープン化が整備されてきています。しかし、攻撃は、そのようなシステムの脆弱性や管理体制の不備を突いてきています。だから、本当の脅威は人や内部の管理体制にあるという認識が重要なのです。
4 つ目は手口。そのタイプは様々です。かつては DDoS 攻撃といいますが、分散型攻撃で特定サイトへの集中的アクセスによる過重負荷でシステム障害を発生させ、サービス妨害を行うようなものが主流でした。最近では、偽サイトへ誘導するフィッシング、上司や取引先を騙るビジネスメール攻撃、WannaCry など身代金を要求するランサムウェアといった経済的利得を狙ったものが主流となってきています。
そういった攻撃は個人がやっているんですか。
そういった攻撃は個人がやっているんですか。
ランサムウェアなどは、例えばビットコインで払えというようなものですか。
そうです。以前、私のところにもビットコインでの支払いを要求する、ランサムウェアを装うメールがきたことがありました。システムは正常で、情報が盗み出された形跡はないのに、メールには正しいパスワードが書かれていました。
それは、日本語だったのですか。
最初はぎこちない英文で、しばらく放っておくと、今度は日本語で来たんです。明らかに日本人が書いた文章ではないため、海外からと考えられます。文面もそれぞれ微妙に異なるため相手が特定の個人なのか、あるいは全く異なる人なのかさえ分かりません。ファイルの暗号化などの被害はなく、とにかくビットコインでの支払いを要求する内容でした。
そのようなメールは、私にも送られて来たことがあります。知人の名義でここにアクセスするようにという趣旨のショートメールがありました。本人に送信の真偽を確認すると「それはハックされたメールだ」ということがありました。海外で流行っているようですね。
そうですね。あとは、IPA (独立行政法人情報処理推進機構) という組織の調査で、2017 年までセキュリティの重大脅威のランク外だったビジネス メール詐欺が、2018 年は 3 位に浮上し注目されています。 最近では、相当に手の込んだもので、防御が大変難しい。ビジネス メールを使った標的型攻撃では、添付ファイルの開封やリンクを通じた特定サイトへの誘導という手口が比較的多いのです。例えば「貴社の商品欠陥に関するクレームです」という標題ならば放置するリスクの方が大きく、会社側は開けざるを得ません。また、ホームページなどで組織内部のことをよく調べ上げ、実在の組織名や名前を使用して「先ほどの会議資料の差し替えです」などの内容のメールを送ってくることもあります。
どうやってアカウントなどの情報を盗み出しているのでしょうか。
方法はいろいろですが、ダークウェブと呼ばれるサイトがあります。これは、Tor (トーア:The onion router) という仕組みを使わないとアクセスできない闇サイトで、他人のアカウントや個人情報、さらには攻撃用のツールなどが売買されています。今はダークウェブで攻撃用ツールが容易に手に入るため、高度な技術を持つ人だと 5 分程度で攻撃の仕掛けを完了できると言われています。それに対して、会社側は「1 年に 1 回パスワードを変更しましょう」などとのんきなことを言っています。
最近では、パスワードの使用をやめようという話もありますね。
パスワード自体は、頻繁な変更より非常に推測しにくいパスワード設定をするか、もしくはトークンを用いた使い捨てのワンタイムパスワードの利用が比較的安心です。また、コストはかかりますが、生体認証も有効です。
不正検査の観点からは、一般に「ログ (操作記録・使用記録) を取れ」と言われますが。
事後的な不正検査ではログは有効ですが、事前の検知はできません。また、ログといっても多すぎて、普通はログを全部見てもなかなか分かりません。ログ分析用のソフトウェアで怪しいログのみ抽出する必要があります。
誰が侵入したかの特定ですね。
そうです。ただ、個人の特定までは難しいです。Tor のように、アクセスの有無は分かっても、そのアクセス元を辿れない場合もあります。
最近では、何でもインターネットに繋がりつつあります。IoT の機器については日本では結構古い時代のものもあるので、本格的に狙われると被害が大きくなりますね。
スマート メーターなどでは、データと物理的な電気やガスの供給がリンクするため、そこを攻撃されると、それは怖いですね。
JAL が 2017 年に 3 億 8 千万円を騙し取られたビジネス メール詐欺事件は、メール アカウントの乗っ取りによるものだとされていますね。
JAL のビジネス メール詐欺は、二件あったうちの一つが旅客機のリース料振込詐欺です。海外の金融会社から旅客機リース料の正規の請求書が送られてきた直後に、本物そっくりに作成された偽の訂正版の請求書を送ってくるという手口でした。この「直後」というタイミングが大事だと思います。
じっくりと検討する時間を与えないわけですね。
はい。偽の訂正版請求書は PDF ファイルで、振込先の変更について書かれていたようです。本来の取引先の金融会社のメール アドレスと 1 文字違いのアドレスから送信されており、画面上は正規の取引先担当者と同一の氏名でメール アドレスもそのまま。正規の画面上に偽装画面をつくる技術もあり、例えば acfe-japan.jp が acle-japan.jp (f が l に変更されている) になっていたりすると、一見ではよく分かりません。文字が長くなればなおさらです。
それでは、対策はどうすればよいのでしょうか。
この種の詐欺を防ぐには、技術的な対策と人的・組織的な対策があります。技術的な対策としては、ヘッダ情報の解析、送信経路の解析、あるいは DMARC (ディーマーク) と呼ぶ送信側のなりすましを防ぐ仕組み、あるいは電子署名による送信元の確認、さらには不審メール検知ソフトなどが挙げられます。
しかし、もっと重要なのは人的対策です。システムを使うのはあくまでも人です。最新のビジネスメール詐欺の手口の周知徹底、不審なメール受信があった場合の迅速な組織内情報共有、類似アドレスに対する目視による確認、送信元への電話等による確認ということが大切です。
最近の手口には、振込の締切日間近に請求書を送付し慌てさせる心理作戦があります。それから、正規の口座が監査中、税務調査中などともっともらしい理由をつけたり、経営者や顧問弁護士などの特定の権限者を騙り、秘密裏に偽の口座に振り込むように指示してきます。
確かに手が込んでいますね。
また、メール宛先の「To」や「CC」を巧みに利用した詐欺メールもあります。例えばメールを送る際に、ある企業の代表取締役である田中さんのメールアドレスを CC に入れて、それが正規メールだと思い込ませるような手口です。田中さんのメールアドレスは tanaka.ko@xxxx であるのにもかかわらず、「tanaka」の次の「.」を「-」に変えて送られると、田中さん本人には届かないのに、受信者は代表取締役の田中さんにも CC で送られていると思い、これは重要な連絡メールだと判断して開けてしまうのです。このような本人以外は気づきにくい違いを利用する、非常に巧妙な詐欺であると言えます。
IT の専門家であれば、ちょっと怪しいかなという懐疑心があるかも知れませんが、ほとんどの従業員や役員は、そのまま信じてしまうでしょうね。
このレベルになると、専門家かどうかはあまり関係ないかもしれません。しかし、本格的なビジネス メール詐欺では、犯人は不正アクセスの試みや、不審メールの送信など、相当な下調べやテストを行っているはずなので、事前の兆候はあったと考えられます。
少額ではありましたが、同様な事件が起こったことがあります。支払い期限が間近な海外取引先から、支払先口座変更のメールが届き、営業担当者は本社の営業部に確認を取り、本社側はそれを許可してしまった。だが、それは詐欺でした。ある一定以上の金額は経理部門の担当で、勘定口座の変更には必ず規定の確認手続きが必要でしたが、営業は支払いの遅延によるペナルティを危惧して、とにかく早急に振り込みを進めてしまったのです。
ですから、システム的な対策だけに頼らず、社内の確認手続きの徹底とか、取引先に変更の真偽を電話確認するといった丁寧な対応が重要なんです。
それが一番大切なんですよね。
ただ、電話確認を行う際に、メール本文中に記載されている偽装された電話番号にそのまま発信してしまわないように気をつける必要があります。メールに書かれている電話番号は使用禁止にし、手元にある正規の情報を利用して電話確認を行うということを徹底しなければいけません。
JAL の場合、香港の口座への送金は、すでに出金された後で、それ以上の追跡が不可能だったようです。
JAL は、会社規模も金額も大きかった故にマスコミが取り上げましたが、小さな詐欺というのは水面下でかなり発生していると思います。
不正検査士マニュアルでも、コンピュータ及びインターネット関連の不正について言及している章 (第1部 13 章) があります。そこでは、内部者によるコンピュータ不正の兆候には、以下のような点が列挙されています。
これには 2 つの視点があります。1 つ目が、不正検査士マニュアルにも書かれていますが、例外事項への対処です。大事な得意先への対応を、内部統制のルール通りに遂行することは誰にでも可能ですが、「ここだけ何とかしてくれ」と部分的な例外対応を求められたときに本当のリスク マネジメントが必要となります。だから、形式的に PDCA のサイクルを回せばそれでよいといったものではないということです。
最近は、国際的にも、IT ガバナンス、要するに経営トップが積極的に関与する体制を取る必要があるという方向に進んでいます。例えば、Chief Security Officer (CSO; 情報セキュリティ担当役員) を任命し体制を整える。それから、適切な権限委譲を明確にする。特にサイバー攻撃が起こったときの大きなポイントは、侵入に気付いたときにシステムをいつ止めるのかという判断がどのレベルで行われるべきかについて、権限委譲などをガバナンス レベルでまず明確にすることなのです。
確かに最近の傾向として、経営層は、サイバー攻撃についても神経質になっていますよね。
はい。最近では取締役会でも「サイバー攻撃の対策は大丈夫か」というようなことが話題に上るようになってきていると言われています。現場で起こっていることが経営層で対処しなければならないリスクになっているため、現場任せにせず、経営トップが率先してこのような問題に取り組んでいくことが重要なのです。
取締役会で、CSO が会社の対策を説明するものの、社外役員はその内容がよく分からないということがあります。「当社は大丈夫です」と聞いただけで、対策は大丈夫なのだろうと安易に満足してしまう。
そういう意味で、取締役会などでの徹底した議論が必要です。あわせて、セキュリティ リスクは必ずしも技術のリスクだけでなく、人的リスクなんだという意識を持つ必要があります。例えば JAL でも、おそらく事前にもあったはずの不審メールへの対応や情報共有などを行っていれば、簡単に振り込んでしまうことはなかったかもしれません。セキュリティというと、対策ソフトの導入などになりがちですが「不審メールがきているので全社的に注意してください」など、トップが明確なメッセージを出すことが重要です。
セキュリティ ソフトを入れればそれで安全と思ってしまいがちですが、そうではないのですね。
そうです。社内の人や組織に対する意識付けが何よりも先決です。JAL のような大きな組織では、当然それなりのセキュリティ対策を行っていたはずです。それでも、ほんの少しの人的なミスや思い込みで事故が起こってしまうのです。
情報セキュリティをあまり意識していない従業員が誤って違法なソフトを自分の PC に導入してしまい、外部からの不正侵入を許してしまったという話を聞きました。侵入した不正なソフトウェアが、ネットワークに感染を広げてしまったと。
ネットワークで繋がっていると、基本的には、全て感染しますね。最近では、セキュリティ ツールによる検知をうまく潜り抜けたり、侵入の痕跡を残さないマルウェアもあり、かなり厄介です。
それを直す時間とコストはどれくらいなのでしょうか。
システムの規模にもよりますが、ネットワークの切断からはじまって、そのリカバリーまで含めますと、時間も費用も相当程度に上ると思います。最悪、バックアップが無いような場合には、アプリケーションやデータをまた一から全部入れ直さなくてはなりませんので、とんでもない時間とコストを覚悟しなければなりません。
それは大変ですね。感染されると被害が大きすぎるので、従業員には定期的に抜き打ちでメール テストを行い、リスクについて常に意識させておかなければならないという気がします。過去に、会社の情報システム部から従業員に偽メールを送信して、それに引っ掛かった人を調査したことがあります。意外にも上層部の方が引っ掛かる結果となりました。
おっしゃる通りで、外から攻撃してもらい、うまく防御できるかを確認する、「ペネトレーション テスト」という侵入テストがあります。今、藤沼先生が仰ったように、不審メールの攻撃を仕掛けると上層部の方ほど開けてしまうという傾向が非常に顕著だそうです。経営幹部ほど不用心なんですよ。
年齢層が高い方が、セキュリティに対する意識が低いんでしょうかね。
今は、どんな仕組みでも侵入される可能性があるという前提で対策を考えるようにシフトしています。要するに早期の検知です。例え身代金を要求するマルウェアがデータを暗号化しても、Windows なら最悪システムの復元で対処できます。ただ、端末に保存していたデータのバックアップをきちんと取っておくことが必要です。
堀江先生は、人的・組織的対応のひとつに「人手による承認・照合の徹底」を挙げています。これはどういうことですか。
オートマチックなセキュリティ ソフトなどだけに頼らないということです。JAL のメール詐欺事件がその一例です。
ソフトウェアだけに頼らず、人手による承認・照合の徹底を徹底しなさいということですね。
そうです。今は、RPA (Robotic Process Automation; ロボットとして動作するソフトウェアによる業務の自動化) のように業務プロセスの自動化が進んでいますが、本当に正規のものかを人手できちんとチェックするという内部統制の「いろは」が整備されていないことがあります。意外に思われるかもしれませんが、高度化する攻撃に対しても、最後は人手で守る以外にないのです。あまりにも技術だけに頼り過ぎてしまっている現状には問題があると思っています。
追加の質問ですが、情報保管をクラウドに移行する会社が最近増えていますよね。そのクラウド自体の管理および安全性について、懸念があります。
クラウド サービス提供者は、大企業から無名の小規模事業者まで数多くあります。パブリック クラウドの場合、あるデータが中国にあるサーバーとロサンゼルスにあるサーバーに分散して置かれていることもありますし、1 つの物理的サーバーの中に競合他社のデータと一緒に保管されている可能性もあります。また、クラウド事業者の破綻リスクもあります。クラウド事業者でどのような内部統制、セキュリティ対策がとられているか、ユーザ企業側から見ますと完全にブラック ボックスです。
たとえユーザ企業側の監査人がクラウド事業会社に出向いても、満足な監査ができることはほとんどないと思います。事業会社の本社会議室でパンフレットを見せられて「私たちはこういうセキュリティ対策を取っています」とか「ここには、廊下からの静脈認証でしか入れません」といった簡単な説明を受けてそれで監査しましたとは言えないでしょう。
そこで最近は、日本公認会計士協会の監査・保証実務委員会実務指針 第 86 号や AICPA (米国公認会計士協会) の SOC2 や SOC3 に準拠した保証サービスが広く利用されています。クラウド事業者が監査法人と契約して、内部統制、セキュリティ対策の評価を受けて保証報告書を作成してもらい、それをユーザ企業が利用するというものです。
なるほど。そうでないと監査ができませんね。
そうです。ユーザ企業側からクラウド事業者に対してセキュリティ対策に関する質問書などを送ってその回答を入手しても、確かめられるのはせいぜい断片的なコントロールの整備状況のみです。クラウド事業者が監査法人と契約をすれば、そこで守秘義務契約が締結されますので、踏み込んだ監査が実施できます。
われわれ CFE は、高度化する IT 不正に対してどんな点を意識すべきでしょうか。
まず、セキュリティ リスクとは業務上のリスクではなく、経営上のリスクとなっていることの認識が重要です。もう一つは、よく「IT のリスク = セキュリティ リスク」と狭く考えがちですが、会社や組織は、セキュリティ対策のためにシステムを導入しているわけではありません。戦略実現との両立、バランスという経営的視点を意識していただけるといいのではないかと思います。
それから、セキュリティ技術者との協働が必要です。セキュリティ技術者をはじめとする IT 技術者は、早急なソフトウェア導入の推奨などの技術的な視点や、防御についての事前対策的な視点の議論に偏る傾向があります。今は侵入されるという前提で考え、侵入された場合に慌てずに、どういう手順で、どういう対応をすべきなのか、業務的な視点で見ていただく必要があると思います。
事後対応と業務的な視点ですね。
はい。不正検査というと、事故後の原因究明という事後対策のイメージがありますが、業務の継続という観点から当然に事前対策も考えなければなりません。つまり、今後は未然防止と共にインシデント発生直後の対応にも視点を持つ必要があるということです。
監査をめぐる環境では、次々に多様な問題が起こっています。テクノロジーの進展が一つの大きなインパクトになることは言うまでもありません。
学会というのは、研究者の集合体であるため、多様性を認め合うことが必要です。歴史研究もあれば、規範研究もあり、実証研究もあります。それらの相乗効果を狙い、研究水準を上げていきたいと考えています。それから、これまで学会というのは非常に閉鎖的で趣味の世界のように見られてきましたが、これからは研究成果をどのように社会に還元していくかが重要です。最近、我々の世界では、実証研究でないと査読付きの学術誌にアクセプトされないという問題があり、若い人たちのほとんどが実証研究に行ってしまいます。この実証研究については、その成果が実務の向上や制度の設計や検討にフィードバックがなされないことに問題があると考えています。たとえば、昨今、内部統制報告制度の見直しなどが議論されていますが、これまでの実証研究の成果がその議論に十分にフィードバックされていません。
学会は様々な考え方やアプローチの混合体であり、それで初めて学会活動の効果を高めることができます。不正検査は監査と相通ずるものがあります。ですから、CFE の方々にはぜひ監査研究学会の活動にも関心を持っていただき、学会にも入会していただけたら、これまでの監査論という狭い枠に留まらないさまざまな議論を重ねることで相乗効果も期待できると考えています。
また、CFE の方々におかれましては、監査の研究者のみならず、公認会計士の方々、内部監査人の方々、監査役や監査委員等の方々、さらに公会計の検査を担当される方々とも是非積極的に交流していただき、監査や検査の世界を広げ、盛り上げていただきたいと思います。
ありがとうございます。
どうもありがとうございました。