しかし、こうした技術負債があると、脆弱性が見つかってもすぐにパッチを当てることが難しく、攻撃を受けるリスクが高まる。そのため技術負債の解消に向けた取り組みが進んでいると認識している。
一方で、経営陣の認識がまだ十分ではなく、取り組みが進んでいない金融機関もあると思う。実際のパッチ適用作業などはITベンダーに依存する部分が大きく、コストもかかる。だが、経営陣が足元で起きている事態の重要性を認識し、必要な予算を確保してITベンダーとのコミュニケーションを継続的にとってもらいたい。
顧客を守る「最後の手段」は一時停止
――セキュリティー人材の需要が高まる中、銀行やITベンダーを含む各業界でリソースの確保が課題になっています。
リソースの確保は重要だが、端的に言えば、ないものは仕方がない。限られたリソースで対応する場合は、例えば現在進めているプロジェクトを調整し、技術負債の解消やパッチ作業を先に進めるなど、リソース配分のプランニングが大事になる。
――金融機関に要請した「短期的な対応」では、システムの「能動的停止」も選択肢とされています。どのような場合に発動を想定していますか。
能動的停止は最後のリスク回避手段だ。システムを止めると顧客や経済活動にも影響を与えることになるので、むやみに発動するわけではない。
例えば、極めて危険な脆弱性を悪用した攻撃が観測され、自社のシステムも攻撃の対象になりかねないケースにおいて、システムの都合上、パッチの適用に3～4日かかるとする。その3～4日を攻撃の脅威にさらし続けるより、一時的にシステムを止めてパッチを適用し、安全を確認してから再稼働する。そうした緊急避難的な措置だ。
サイバー攻撃を受けて数カ月にわたりオペレーションが止まるおそれがある場合には、システムをいったん止めてコントロール下に置くほうが望ましい。もはや従来のように、「何が何でも金融サービスは止めません」ということではない。
――能動的停止に至る局面は近づいていますか。
感覚的には、脆弱性の総数が大幅に増えているため、深刻度が「HighやCritical」に該当する絶対数も増えている印象だ。そもそも「短期的な対応」の中に能動的停止を入れた背景は、攻撃者側の脆弱性検知能力が極めて高くなったことで、自らシステムを遮断する事態が起こりうると思っているからだ。
ただし、システム障害のように意図せず突然止まるわけではない。能動的停止は計画的にシステムを止めるので、リカバリーに備えてデータの整合性を維持した状態で停止させることができる。その分、突発的な障害よりも復旧しやすい。
――システムを止めると、サービス提供を継続できなくなるおそれがあります。その際の顧客対応をどのように進めていきますか。
重要なサービスにはBCP（事業継続計画）が用意されており、簡易的なバックアップ用ツールのもとでサービスを継続するケースもあれば、マニュアル作業（手作業）で継続するケースもある。また、ネットバンキングを止めたとしても、日中であれば店舗やATMといった代替手段を案内できる。
ただ、BCP対応で処理できる量は限られるため、処理能力の低下は避けられない。これまで日本では「金融サービスが止まる」ことへの許容度が低かったが、これだけサイバー攻撃が高度化・高速化する中では、顧客情報や資産を守るうえで「計画的に止めさせていただくことがありうる」と認識してもらう必要がある。そのことを理解してもらえるよう、コミュニケーションを図っていく。
防衛の軸は「パッチ対策」
――メガバンクが「ミュトス」にログインできるようになりました。 脆弱性の発見やパッチ適用作業にも変化が起きていますか。
アクセスできるようになっているかについては答えられない。そもそもログイン制限のないAIモデルも十分に高性能であり、ミュトスにログインできなくても、AIを活用したさまざまな対策が行える。日本の金融機関はAIの活用がまだ十分に進んでいないので、作業部会としても活用に向けたメッセージを出していこうと考えている。
――「ミュトス」にログインできるようになると、脆弱性が公表される前に攻撃される「ゼロデイ攻撃」への備えを強化できるようになるのではないですか。
理屈上はそうだが、ミュトスにログインできるからといってセキュリティー対策が盤石になるわけではない。
そもそもソフトウエアには、大きく3つのタイプがある。1つ目は、マイクロソフトなどが提供する「製品」で、利用者側からソースコードにアクセスすることはできない。 2つ目は、オープンソースソフトウエア（OSS）。ソースコードが公開されているため、われわれも解析できるが、基本的には開発側が脆弱性を検知する。そして3つ目が、自社でソースコードを書く「自社開発」のソフトウエア。公開しておらず、自分たちだけがアクセス権を持っているため、自ら脆弱性を検知する必要がある。
攻撃者はネットワーク内部への侵入を狙う際、どこを攻撃してもいいわけだが、1つの金融機関にしか有効でない自社開発の非公開ソースコードの脆弱性をピンポイントで狙う優先順位は低いはずだ。フロンティアAIモデルを使って自社ソースコードをスキャンし、攻撃者に発見される前に脆弱性を解消しておくことは有効だが、OSSのほうがはるかに狙われやすい。
自社ソースコードの脆弱性リスクが低いとは言わないが、全体のリスクを見たときに、自社のソースコードのスキャンよりも、OSSなどのパッチ適用の高速化にリソースを振り向けるほうがよいという判断もある。
※ログイン後、コメント入力が可能です。