米国発 ～ ある日本人サイバーセキュリティアナリストの日常

脆弱性対応「何かあったら対応します」では遅すぎる。サイバー・カルチャーを変えていくことから始めよう（1/2 ページ）

　私は米国の小売業の情報セキュリティアナリストとして従事しています。所属チームは合併及び買収（以下M＆A）と事業売却（Divestiture）のセキュリティを専門に扱っています。過去３年程リテールの事業売却におけるITシステムの分離プロジェクトのセキュリティを担当しており、現在は、合併吸収におけるITシステムのインテグレーションプロジェクトのセキュリティを担当しています。

　本稿では、セキュリティ実務者としての視点から、事業売却（Divestiture）のシステム移行の過程で得た経験を踏まえ、企業間におけるセキュリティおよびカルチャーの相違をどのように克服したかについて、具体的な事例を交えて共有します。

　まず事業売却とは一般的にあまり馴染みのない言葉ですが、企業が自社の強みと合致しない事業や成長が見込めない事業を切り離すことで、主要事業に経営資源を集中させる事です。買い手の選定、契約締結、事業の引き渡しなどの過程を経て実現します。今回は事業引き渡しの際、システム切り離しのステップでの体験談を共有します。

システム移行は一夜にしてならず。

　合併・吸収（M&A）や事業売却（Divestiture）の際に行うシステム移行は、決して一晩で完了するものではありません。システムの規模や、統合（インテグレーション）、分離（セパレーション）の範囲によって、移行にかかる時間は大きく異なります。簡単なケースでは、60日から90日ほどで移行を終えることもありますが、規模が大きくなると、2～3年もの時間を要するのが一般的です。このような大規模な移行には、慎重で計画的なアプローチが求められるのが現実です。

　システム移行は単なる技術的な作業だけではなく、ビジネスプロセスや、データやサプライチェーンの移行も絡んでくるので、非常に複雑です。そのため、移行を進めるにあたっては、まず、システム及びデータの在庫管理を行い、技術面に加え、人的資源や組織の調整、リスク管理といった視点でもしっかりと準備を整えます。

　具体的にどのタイミングでシステムを移行するのか、またどのステップで変更を加えていくのか、リスクをどう管理していくのかを計画段階でしっかりと決めておくことが、移行をスムーズに進めるためのポイントです。

　また、一度決定した計画はよほどの事象が発生しない限り、変更せずに進めていくという取り決めもこの段階で行われます。このようにシステム移行は、単に「技術的な作業」ではなく、全体を見据えた戦略的な取り組みが欠かせないのです。

システム移行中は非常に脆弱な時期である。

　インテグレーションやシステム移行の過程では、2つの組織のさまざまな要素が並行して動いているため、非常に複雑で動的な状況が展開されます。例えば、異なるシステム間でのデータ移行や通常業務の変更、調整、従業員間の役割変更、そして新たなガバナンス体制の構築などが同時に行われます。

　しかしその一方で、通常のビジネス運営も継続しなければならず、例えば顧客対応や製品・サービスの提供など、日々の業務が停止することはありません。このように、システム移行中は、業務の正常性を維持しながら、組織の統合や変更が進行するため、非常に脆弱でリスクの高い状況が多くなります。

　システム統合や移行の最中に、ゼロデイ脆弱性や重要度の高い脆弱性が新たに発見された場合、迅速かつ適切な対応が求められます。例えば、ゼロデイ脆弱性が発覚した際には、既知の修正パッチが提供される前に悪用されるリスクがあるため、まずは直ちに該当システムの隔離やアクセス制限を強化し、追加のセキュリティ対策を講じる必要があります。

　また、ビジネス運営を継続しつつ、影響範囲を最小限に抑えるために、全体のリスク管理計画やインシデント対応体制の強化も欠かせません。こうした状況では、脆弱性の深刻度に応じて、緊急の対応手順を策定し、影響を受けるシステムやプロセスを把握しておく必要があります。

　2021年末に話題となった「Log4Shell」というセキュリティ脆弱性について、記憶にあるでしょうか？　これは、非常に広く使用されているログライブラリ「Log4J」に存在していた脆弱性で、攻撃者がリモートでコードを実行できるという深刻な問題を引き起こしました。

　Log4Jは、Javaベースのアプリケーションに欠かせないツールであり、システムのログ記録を行うための重要なライブラリです。しかし、2021年12月にセキュリティ研究者によって明らかにされたこの脆弱性は、悪意のあるユーザーが特定の文字列をログメッセージとして送信することで、リモートコード実行（RCE）を引き起こす可能性があることが判明しました。この脆弱性は瞬く間に広がり、多くのシステムに影響を与えました。

　特に、クラウドサービスやインターネット接続されたシステムを利用している企業や開発者にとっては、大きなセキュリティリスクをもたらすものでした。そのため、迅速にパッチを適用しなければならない状況となり、対応に追われました。幸い、Log4Jの開発元であるApache Software Foundationは、早急にアップデートを提供し脆弱性を修正しましたが、発見から数日間は多くの攻撃が行われました。

　この出来事は、ソフトウェアにおけるセキュリティの重要性を再認識させるきっかけとなり、依存しているライブラリやコンポーネントの管理がいかに重要であるかを改めて考えさせられました。そして、これを契機に、ソフトウェア開発者をはじめ、全ての企業がセキュリティ対策を見直し、サプライチェーン攻撃のリスクにも注目し始めたことは、皆さんも知っている通りです。

　リテール業界においても、この問題は決して例外ではありませんでした。弊社も、24時間体制で脆弱性対応に追われることとなりました。このような状況下で、対象となる企業に対して迅速に対応を求めましたが、その反応は予想外でした。「“We are aware of the vulnerability and will act accordingly when the incident occurs.”この脆弱性については認識していますが、何か問題が発生すれば対応します」との回答を受け取ったのです。この一言に、私たちはサイバー・カルチャーの違いを強く感じざるを得ませんでした。

米国発 ～ ある日本人サイバーセキュリティアナリストの日常

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  【新連載】M＆Aが決まったら、セキュリティチームは何をどうする？

• 

  迷宮化するセキュリティ対策、脱出の鍵は「自分の頭で考える」こと――Armoris 鎌田敬介氏

• 

  10年の経験を経たRecruit-CSIRTに見る、平時とこれからのCSIRTのあり方――リクルート 鴨志田昭輝氏

• 

  事前・事後の対応を年間数百件に上る緊急出動事例からアドバイス――ラック サイバー救急センター長 関宏介氏

• 

  予防は治療に勝る「プロセスのゼロトラスト化」を軸に多面的な取り組みを展開――全日本空輸 和田昭弘氏

• 

  デジタルアイデンティティこそがデジタル覇権の行方を左右する――東京デジタルアイディアーズ崎村夏彦氏