【新連載】M＆Aが決まったら、セキュリティチームは何をどうする？：米国発 〜 ある日本人サイバーセキュリティアナリストの日常（1/2 ページ）
M＆Aは新たな可能性を生む一方で、セキュリティやコンプライアンスのリスクも伴う。またインテグレーション中はシステムが脆弱な状況にあるため、適切な対策を講じることで、より安全かつ成功に導くことができる。
私は米国の小売業の情報セキュリティアナリストとして従事しています。所属チームは合併及び買収（以下M＆A）と事業売却（Divestiture）のセキュリティを専門に扱っています。過去3年程リテールの事業売却におけるITシステムの分離プロジェクトのセキュリティを担当しており、現在は、合併吸収におけるITシステムのインテグレーションプロジェクトのセキュリティを担当しています。
今回はセキュリティ実務者の視点から、M＆A の重要項目をいくつか共有します。
M＆Aの交渉を進めるにあたって、恐らく買収元の企業経営陣は買収企業の財務、運営などのDue Diligence（適正評価）を行っても、買収企業のシステムセキュリティを十分考慮して契約を結んでいるとは考えにくい状況です。
少なくともセキュリティが不十分というだけで買収を撤回するということはあまりなく、ある程度のリスクを含め買収を遂行します。というのも、それは会社経営戦略によるビジネスディシジョンであり、セキュリティの管理はシステムインテグレーション時に克服できるだろうという視点でいるからだと思います。
M＆Aにおいてセキュリティのデューデリジェンスは、契約成立前に行うのが一般的です。通常、初期のデューデリジェンスは契約交渉の過程で実施され、対象企業のセキュリティ状況を把握するために、情報の開示を求めたり、インタビューを行ったりします。このプロセスの詳細は後述します。（現実的にこのプロセスが実施されずに買収契約が進んでしまうことも多々あると思います。）
そして契約成立後には、より詳細な技術的評価やシステムへのアクセスが可能になることが多いです。この段階で、具体的なセキュリティ対策や脆弱性の診断を行うことができます。契約前にシステムに触れることは、法的および契約上の制約があるため、通常は難しく、例えばA社が買収対象企業に対し契約成立前に脆弱性スキャンを実施するのは単なるハッキングをしている事と同様でありできません。また同じ視点から考えると買収対象企業保有のデータも、契約前は別企業のデータとみなされレビューなどはできません。
デューデリジェンスにおいて、セキュリティ評価は非常に大切で、買収企業のセキュリティインフラやポリシーを調査して、脆弱性やリスクを特定しなければなりません。大手企業など買収を頻繁に行う企業は、専門のチームがこの業務を行い、プレイブック（手順書）を元にデューデリジェンスを行い、内部連携を図るとスムーズに進みます。
「プレイブック」とは、戦略ガイドやリスク管理の手順書として管理されている文書のことで、特定のプロジェクトや問題に対処するための手順や、戦略をまとめた文書やリソースを指し日本語では馴染みが薄い言葉ですが、欧米では一般的に使われています。
新しいプロジェクトやキャンペーンを実行する際の計画やベストプラクティスが含まれていて、M＆Aプロジェクトを運営するうえで概要、目的、手順、スケジュール、参照すべきポリシー及びコンプライアンスレビュ一、各部署の担当者などが記載されています。
各プロジェクトチームが文書のオーナーとなり定期的に更新します。また、特定の買収企業のインテグレーションが完了した時点で、プロジェクト毎にもプレイブックが作成されます。プロジェクト毎のプレイブックは非常に重要な文書で、プロジェクト完了後監査が行われる際に求められます。要するに、プレイブックは、特定の状況での行動計画や戦略を示したドキュメントであり、効果的な意思決定をサポートするための重要なツールです。
プレイブックは買収契約時のインテグレーションプランの規模やスケジュールによって異なりますが、決められた期日までに行うタスクとして、初日、初めの2週間、30日目、60日目、90日目とプロジェクトの流れを決めて進めます。ディペンデンシー（システムの依存関係）を明確にすることを求められ、例えばアプリケーションとデータベースの依存や外部のAPIに依存しているアプリケーション、特定のオペレーティングシステムが特定のハードウェアに依存する場合などがあります。
そして買収の契約内容にもよりますが、契約がクローズしてインテグレーションが始まると、多方面でのセキュリティタスクが課されるわけです。
買収契約が成立すると同時に買収企業のテクノロジーももとより、リスクもそのまま受け継ぐことになります。確認するべき主要な3点をあげます。
（1）買収元の全システムの策定。システム概要を把握し、整理、そして具体的な形にどのようにシステムを連携構築が必要か、そしてそれがシステムインテグレーション時に、ターゲットテクノロジーがスムーズに連携できるのかを見極める作業です。
（2）それにかかるトータルコスト及びメンテナンス費用の概算。
（3）連結後の（将来的な）システム拡大の容易さ、例えば合併によるユーザー（従業員、顧客）の増加、トランザクション増加、サービス数の増加なども考慮する必要があると考えます。
ここで（1）〜（3）で述べたことをブレイクダウンしてみます。
（1）に関してどのシステムを統合するか、どのように統合するかを明確にした計画を立てます。この時に最も考慮しなければならない事はいかにビジネスインパクトを抑えるかです。ここでいうビジネスインパクトはAvailability（可用性）のことです。コアシステムがダウンしてしまうと通常業務に支障がでたり、損失が発生してしまったりするからです。脅威から守ることは当然ですが可用性からもビジネスを守るためのセキュリティであることを常に考慮します。
また現行システムの分析も行います、 買収企業のシステムを評価し、機能や性能、セキュリティ面を確認します。ポリシー及びコンプライアンスのギャップを詳細に分析する必要があります。
例えば買収企業のコアシステムに2段階認証が行われていないと明らかになったり、重大な脆弱性が発見されたりした場合、プライオリティタスクとしてインテグレーション計画を進めていく必要があります。
データ保護も重要です。取引中に扱う機密情報や顧客データの保護が必須です。情報漏洩を防ぐための対策を講じなければなりません。インテグレーションの期間中はシステムが非常に脆弱な状態にあると常に認識してください。
（2）に関しては（1）で述べたプロセス全体におけるコストの分析も必要になってきます。インテグレーションを進めるにあたり、現行システム同士の統合を検討する場合が大半を占めると推測しますが、時には新しいソリューションを導入する方がコストを抑えられる場合もあるわけです。
企業の規模が大きくなればなるほど、それに伴うライセンシング費用も大きくなるので、セキュリティのコスト分析も大切なタスクです。例えば、買収元のA社とクラウドサービスの契約が3年程残っている状況でインテグレーションプランを計画するよりも、思い切って自社クラウドソリューションへ移行しインテグレーションを進めれば、契約済みの今後3年分のクラウド費用は無駄になるかもしれませんが、長期的に見ればポリシーやコンプライアンスの統合もできるので管理コストとリスクを抑えられるため、トータルのメリットが大きいという考えです。これはあくまでも例え話で実際にはケースバイケースになるでしょう。
そして（3）で述べたシステムのスケーリングは、買収後の事業・サービスの拡大、従業員の増加、顧客の増加など将来的なスケーリングを考慮して、インテグレーション計画を進めていくビジョンも持ち合わせなければなりません。
例えば、買収によって従業員数が4000人増加となり、顧客数も5万件増加となればそれに伴う人事データ、決済データ、顧客情報データなどさまざまなデータが増加することは確実ですから、現行のシステムのスケーリングのしやすさ、及びそれに伴うセキュリティ管理も見落とす事はできません。これについてはシステムを利用するビジネス（またはサービス）の経営上の成長戦略も関わってきます。
ここまでインフラシステムのインテグレーションばかり述べてきましたが、人事的観点からのセキュリティタスクとして忘れてはならないのは、セキュリティアウェアネストレーニングです。セキュリティ意識の向上を目的として 新しいセキュリティポリシーや手順について従業員を教育し、意識を高める必要があります。
Copyright © ITmedia, Inc. All Rights Reserved.