名古屋工業大学大学院教授 渡辺研司氏

社会は個別組織でだけ成り立ってるわけではなくて、いろいろな部品から1つの製品が作られているように、さまざまな企業がサプライチェーンでつながっている。これを相互依存性と呼ぶが、サプライチェーンだけではなくて、社会経済活動を支えている電気やガス、水道、通信、金融などのインフラストラクチャー、さらには、法体系や行政機能などいくつもの階層が重なり依存しあって1つの社会を形成している。

こうしたネットワーク型社会により、分業化が進み、効率性が向上していることは良いことだが、一方で、何か障害が発生したり、途中のサプライチェーンのラインが分裂した瞬間に、ドミノ倒しのように、広い範囲に障害が波及してしまう。

そこで、レジリエンスという考え方が必要になる。今、政府では「強靭化」と訳しているが、本来はしなやかな復元力、弾力性のある回復力というような意味。もう少しわかりやすく言えば、被害を受けることを前提に、結果が元と違うことになったとしても自分の進むべき方向に立ち上がり進んでいくという、打たれ強さということになる。

このレジリエンスを考えた時に、組織単体がいくら頑張っても限界があり、自分が依存してるもの、依存されてるものも含めて、どうやって機能を確保していくかを互いに調整しながら対策していくことが求められる。これが今のネットワーク型社会に求められることだろう。

ただし、複雑化した社会の中では、自分がどこまでのサプライヤーなどのステークホルダーとつながってるのか、何に依存してるかを、すべて把握することは難しく、事前の対策を完璧にするとか、水際で食い止めるということは、もはや限界だ。したがって、レジリエンスの概念にあるように、いざ突破された時の対応能力、レスポンス能力というものを積み上げていくことが求められてくる。

システムに関して言えば、大量・高速処理、24時間365日運用、リアルタイム処理、ネットワーク化、分散処理、マルチプラットフォーム、マルチベンダー、クラウドコンピューティング、ビッグデータ、IoTなどのキーワードが今のシステムには要求されている。

私が20年ほど前に勤めていた銀行では、当時からもちろん大量高速処理をしていたが、今ほどのスピードと量は考えられなかったし、365日24時間リアルタイムでの処理も求められていなかった。

何かシステム障害や事故があれば、人海戦術で何とか処理できたことが多かったが、今ではそれは困難だ。

一方、ここ10年ほどのICT障害事例を見ると、発生分野や、社会・経済活動への影響パターンが多様化していることがわかる。

ネットワークでつながったシステムは、障害が発生した時に、広がる連鎖障害を早く食い止めないと経済的損失がどんどん増加してしまう。ネットワーク経由で他のシステムの不具合が及んでくる可能性もある。

昔は、銀行も行員とベンダーがほぼ一緒にシステムを作り上げていたので、何か不具合が発生しても、どこに脆弱性がありそうだとか、次にダウンするとすればどの辺だというのが、お互いにわかっていたので、電話1本で連携・対応することができたが、今日のようなマルチベンダー体制では、システム障害・事故が発生した際に、どのシステムが悪さをしてるかというのが、なかなか把握しにくい。「なんだか今日はシステムのパフォーマンスが悪い。オペレーションが多いせいなのか」と、単なるシステムの不具合と思わせるようなサイバー攻撃も登場している。ベンダーに問い合わせても、「うちのせいじゃないと思います」とたらいまわしにされ、原因はいつまでも特定できない。逆に言うと、サイバー攻撃はそういうところを突いてくる可能性もある。

セキュリティーに関しては、いろいろなツールやセンサーも開発されているが、後付けでそういったものを入れても限界がある。また、基幹システムが老朽化・複雑化・肥大化し、例えば老朽化されたモジュールの上に、いろんなアプリケーションが上乗せされているようなことも多く複雑怪奇で、それを設計した人達は引退しているという世界になってしまっている。

できれば、後付けにするのではなく、システムの更新の時期を早めてでも、基本設計の段階でサイバー攻撃を意識したシステムの脆弱性をカバーするような仕組みを入れておくことが望ましい。

システム障害は再現できる

一般的に、システムには、安定性、堅牢性、可用性、拡張性、安全性、柔軟性、信頼性が求められるが、経営効率化(コスト削減、アウトソーシングなど)に伴い全ての機能を維持するのは困難だ。そして1つでも欠けたところから問題が拡散してしまう。

2010年に、ニューヨーク証券取引所で、システムの意図しない連鎖障害によって、高速取引による大量の売り注文が発生し、過去最大の下落幅を記録したケースがある。ダウ平均指数は14時30分には1万600ドル前後だったが、14時47分には9870ドルと一挙に前日比マイナス9.2%とブラックマンデー以来の大暴落を記録した。15時には1万410ドルまで回復したが、原因究明は長期化し、その間、①証券会社の誤発注、②プログラム・ミスなどが原因として報道された。いずれにしても、何らかの理由で売買の需給バランスが瞬間的に崩れたことが引き金となり、HFT(高頻度プログラム取引)や、個別銘柄のボラティリティを制御する仕組みが機能しなくなり、さらに、同一銘柄が複数の市場で取引される市場構造が、問題を増幅させたといえる。

その後、米証券取引委員会から出された事故報告書では、ある特定銘柄に対する、ある証券会社の取引プログラムの売り反応に、他の証券会社の取引プログラムが呼応して売りの連鎖が急拡大したことが要因とされたが、ポイントは、今回のようなシステム間における人間が意図しない連鎖的な暴走が起きないとしても、サイバー攻撃などによる意図的攻撃による再現可能性はあるということ。つまり、空売りとか、意図的に株価を操作したいような時、あるいは市場や何かを混乱させようとした時、こうした動きをデータとして投げ込めばいい。

もう1つの例は、翌年、2011年3月の東日本大震災直後に、大手金融機関の義援金の振込口座の設定ミスにより、大規模な振込・ATMサービス障害が発生した事故である。都内2支店の複数の口座にあらかじめ設定されていた上限件数を超える大量の振り込みが集中したことが発端となった。

銀行の口座というのは、いつどこで、いくらを下ろしたのか、誰から振り込みがあったかログを通帳に記帳印字したり、ウェブ表示できるように保存しておく仕組みになっているが、義援金では、短時間に多くの小口を含めて大量のデータが入ってくるので、そういった記帳ができるような形でのデータのログは残さない。その設定を間違えただけで、データがオーバーフローして、振込・ATM障害が3日間にわたり発生した。災害時、現地にお金を送りたいとか、あるいは、現地でお金を下ろしたい方が多くいらっしゃったにも関わらず、銀行がそれを全うできなかったという意味では、大変、当事者の方々も、不名誉かつ大きく反省されたケースであろう。

 

リスク分析の手法

リスク分析の手法でイベント・ツリー・アナリシス(ETA)という手法があるが、これは、何か事象が起こると、次にどのようなことが起こり得るかを、木の枝になぞらえて、時間経過とともに展開していく考え方。例えば、地震が起きると、どのようにシステム障害が拡大・波及していくかということが分析できる。

一方、フォルト・ツリー・アナリシス(FTA)という分析手法は、何か障害が発生が懸念されるときに、その障害はどのような原因によって起こり得るのかを遡って分析する考え方。例えば上記の銀行のシステム障害で、他にどのような原因で同じようなシステム障害が起きるかを考えると、停電であったり、システムの統合によるミスであったり、人為的なヒューマンエラーであったり、あるいは、外部犯行やサイバー攻撃も原因になり得る。つまり、多様な要因による再現可能性を意識しなくてはいけないということだ。自然災害だからこうなってしまったというのではなく、その現象はたまたま自然災害によって引き起こされたが、他の要因でも発生する。ここに複数の脆弱性があるということを認識して、それらの脆弱性を潰すことも忘れなく対策していく必要がある。

 

システム自動化の功罪

もう1つはシステムの自動化による功罪という点からも対策が求められる。高度に自動化されたシステムにおける人間の仕事は、自動装置が設計通りに動いていることを確認するだけでいい。しかし、それは同時に担当者のモチベーションや緊急時の対応能力の低下を招き、極めて稀にしか起こらない異常を見つけることが難しくなる、というジレンマを生み出している。そのような弱点をついてくるサイバー攻撃もある。

皮肉な話だが、頻繁に障害が発生するシステムをお持ちの会社は、現場では高度な対応能力を身に付けているわけだが、こうした技量は、サイバー攻撃を実際に受けた時に、検知する力にも役立っているかも知れない。

つまり、人間と機械の関係を考えた時に、自動化が進んでいるシステム群に対して、何か通常時でないことが起きた時に、それをどうやって検知できる能力を身に付けるか、ここが大きなポイントになってくる。

システムを能動的に止める

一方で、サイバー攻撃の目的や手法は、高度化、複雑化している。まず防がなくてはいけないのが検知のタイミングが遅れること。また例え検知ができても、原因究明をしてる間にどんどん被害が広がるので、障害対応として、システムを継続させるだけでなく、能動的に止めるということが、しっかりできるかが、今問われている。

例えば、これ以上システムを動かしておくと、被害が拡大するので、システムの停止により被害を受けるお客様には迅速に通知をし、同時に損害賠償金の支払い準備を始める、というような、能動的に止めることによりインパクトを最小化させる判断をしていかなくてはいけない。判断が遅れたら、ずるずると攻撃をされ続け、対応は後手後手に回ってしまう。

情報セキュリティだから機密性を死守しなくてはいけないという考え方だけではなく、場合によっては機密性を下げてでも可用性を上げなければならない時もあるし、ある時は、完全性を担保するために可用性を下げなくてはいけない場合もある。現場がそれを判断できるような権限委譲と、それらのジレンマを感じながら意思決定する訓練、演習もしていかなくてはいけない。

現場と経営の間を取り持つCSIRTの役割も不可欠だ。今起きているシステムトラブルは経営上どういう影響をもたらすのか、売上がどれだけ下がるのか、お客様にどれだけ迷惑がかかるのか、それとも社会全体に迷惑がかかるのか、それはどの程度の規模なのか、どの時点で経営者が謝らなければいけないのか、CSIRTは、こうした問題をわかりやすく翻訳し、経営陣に説明し意思決定を求めなくてはいけない。

こうした対応はトラブルが起きたその時にいきなりやれと言っても無理で、あらかじめ、経営上どの業務が最も重要なのか、その業務が止まることで経営にどのような影響を与えるのか、その業務を支えているリソースはどのようなものがあるのか、いわゆるビジネスインパクト分析(BIA)をしておくことが求められる。BIAがなくては、経営陣としても、次のアクションが決められない。

もう1つは、コネクト・ザ・ドッツ(connectthedots)、という考え方が重要になってくる。ポツポツと散発的に起きている事象や問題点を、上部に報告するエスカレーションの仕組みを持ち、それらをつなぎとめることで、今、起きていることや、これから起こることの全体の状況を推測するような体制を構築しておくということ。攻撃者はタイミングをずらしたりして少しずつシステムに侵入、あるいは複数ポイントから同時多発的に攻撃してくるので、部分的な事象をつなぎ合わせて攻撃の傾向や目的を早期に見極めることができれば、この攻撃手法だったら、次はここに来るだろうということを予測し専門のサービス会社と連携したり、あるいは行政部門とも連携することで、先手を打ったり、攻撃元が突き止められることも可能かもしれない。また、攻撃は1回だけではなく、複数回繰り返されることを前提に構えていく体制も重要になる。

演習・訓練が最も重要

自然災害にしてもサイバーセキュリティにしても、BCM活動についてはPDCAサイクルが重要になる。その中でも一番重要なのが演習・訓練だ。

繰り返しになるが、これまで経験したことないようなサイバー攻撃を受けた場合は、被害を最小限にとどめるためには、重要な基幹システムであっても、あえて能動的に止めなくてはいけない、けれども経営者としては止めたくない、社会的責務があるので止められない、という挙棋不定の状況に陥ることが予想される。そのような場面において、意思決定をしていくようなリアルな演習をしていかなくてはいけない

演習・訓練の手法は、ISOで定義されている。訓練は「ドリル」という意味で、決められたことが手順どおり、時間通りにしっかりできるように繰り返し練習することをいう。決められた行動を台本通りにミスがないように実施する。一方、演習というのは応用であり、断片的な情報やガセネタも含めて、シナリオとして与えて、極限状態において、どう意思決定をしていくかをトレーニングする。必ずしも正解はないが、本番で対応できる力を身に付けるものである。

決して演習参加者を困らせることが目的ではなく、どういう部分について脆弱性を感じ、克服したいと思ったのか、前もってどのような対策をしておけばよかったのかなど、演習の場合には、できなかったことや課題をより多く見つけるほうが効果的だ。

すでに多くの組織で自然災害については防災訓練をやっているだろうし、サイバー攻撃についても情報システム部主催の訓練などをやられているかもしれない。が、レスポンス(対応)という観点からいくと、もう少し、幅広く、例えば災害時はサイバー攻撃にとっても、絶好のチャンスともなるので、災害とサイバー攻撃が複合的に起こるような状況を想定したシナリオがあってもいい。

こうした演習を行う場合には、システム部門とビジネス部門が別々にやるのではなく、「事業継続」というくくりで、有機的に互いが関わり、一緒にシナリオを作り、合同で訓練をして、どのタイミングでどの情報をどう共有・協議していくかなどを検証していくことが大切だろう。

[2016年4月8日に開催したIT-BCPセミナー講演より]