セキュリティ対策：インソース（内製）／アウトソース（外注）の境界は？

日本は海外と比較してセキュリティ意識が高いとされている。ウイルス対策ソフトの導入率も高く、各種アンケート調査でもセキュリティ対策は重要と答える経営層も多い。ISO 27000シリーズの認証取得率はインドや中国を抜いて1位（2023年ISO/CASCO調査※1）だ。しかし、現場の視点では違った意見もある。

セキュリティ担当者からすれば、人材不足や十分な予算が当てられない、評価されないといった声をよく聞く。経営層としてもセキュリティの重要性は理解していても、ベンダーがいうソリューションをすべて導入できるわけはない。実際、すべての対策を導入する必要もないし、またすべきでもない。

セキュリティ対策において、むしろ重要なのは全部やるではなく、すべきことをする、できること、できないことを明確にすることだ。すべきだが、自分たちでできないことは、アウトソースすればいい。これは、リスクマネジメントで規定されている「リスク転嫁」の合理的な考え方だ。

たとえば、ECサイトを運営するとき、カード決済に関するセキュリティシステムや認証インフラを自社で開発、運営するのではなく、決済サービスを利用したり、カード会社のサイトに丸投げしたりすることがある。これは、システムコストを下げることが目的ではない。より高度なセキュリティ対策を専門サイトに委任することで、自社の責任範囲を限定して余分なリソースやデータを持つリスクを低減させることが目的だ。リスクの外部転嫁のひとつである。

どれを自社でやり、どれを外注するか。インソースとアウトソースの切り分けについては、日本ネットワークセキュリティ協会（JNSA）および日本セキュリティオペレーション事業者協議会（ISOG-J）が公開している「セキュリティ対応組織（SOC/CSIRT）の教科書～x.1060フレームワークの活用～」が参考になる。

この文書（以下「セキュリティ教科書」とする）は、ITU-TのX.1060勧告に準拠するものだが、この勧告の作業部会にISOG-Jのセキュリティ教科書を作成したスタッフが参加している。お互いに情報や内容を補完しあっている部分もあり、双方の文書の理念や目的に共通点は多い。そして、セキュリティ教科書は、日本向けに編纂されており、日本のセキュリティ対応組織にチューンされているといってよい。

なお、セキュリティ教科書は、SOCやCSIRTが考えるべき業務のフレームワーク、インシデント対応の考え方、実践方法などを解説している。付録資料としてExcel形式の業務成熟度チェックシートがあり、組織ごとのセキュリティ対策の状態、強み、弱みなどの分析に役立てることができる。

セキュリティ教科書は、SOCやCSIRTの業務について、包括的・網羅的に書かれているが、重要なのは「書いてあることをすべて実施する必要はない」ということだ。リスクマネジメントの常として、リスクは組織や業務ごとに異なる。対策や対応は優先順位をつけて行うべきで、つまりできないこと、やらなくていいことはやらないことの方が重要である。

インソース／アウトソースの切り分けについてはセキュリティ教科書の6章に詳しく書かれている。ここでは、対応組織が実施、提供するセキュリティ業務、セキュリティサービスについて、インソース、アウトソース、併用、未割り当ての4つに分類している。

インソースやアウトソースの切り分けはどう考えればいいのか。教科書では、取り扱う情報が組織内か外部からなのかと、専門スキルの必要性の度合いを考えよとしている。ここで、情報が外部にあるか、攻撃者側にある場合は、外部とする。組織内の情報、被害者側の情報は内部とする。情報の内外を横軸、そして対策に専門スキルを必要とする度合いを縦軸として考える。

すると、次のようなマトリックス図を作ることができる。

この図に従うと、第1象限：自社組織で実施すべき領域が、インソースすべき施策、業務ということになる。第3象限：専門組織で実施すべき領域がアウトソースに適したものとなる。第2象限、第4象限はインソース、アウトソースの併用となる。内製と外注の責任範囲、カバー領域によって、インソース寄り（第2象限）、アウトソース寄り（第4象限）と分類される。

第1象限：
必要なセキュリティ対策やソリューションについて、関連する情報は外部のものか、外部に属するものかを考えて、内部の場合、かつ専門性が低いものはインソース、内製を考えるべきとする。専門性が低いというのは、自社でもできるという場合と、自社にしかできない場合も含まれる。自社にしかできないことは、一般的な専門性とは関係なく、内部的なスキルが求められる。

第2象限：
情報が外部に属するもののでも、専門性が高くない、組織内スキルが優先される場合は、主たる管理をインソースで行い、支援やサポートをアウトソースする

第3象限：
外部の情報、攻撃者の情報は自社管理、自社収集に限界がある。また、外からの攻撃への対応は高い専門性を持つ。攻撃手法や攻撃者コミュニティに関する知見や接点も必要だ。システム内部の高い分析も求められるので、自社で対応することは困難といえる。アウトソースの領域となる。

第4象限：
内部の情報、被害者側の情報だが、扱いや防御が難しい場合、高い専門性が必要な場合は、外部の専門家に主たる業務をアウトソースしながら、内部スタッフも支援や監視を行うことになる。

具体的な例に当てはめてみると、取引先台帳や名簿などは、内部情報であり秘匿性もある。だが、扱いは暗号化やアクセス制御など比較的平易な技術で守ることもできる。インソースのみで対応することが適切となるだろう。しかし、ユーザーのクレジットカード情報は、組織外の情報であり、取引での扱いには金融関連法の規定、PCI DSSのような国際基準への対応が必須である。アウトソースが有力な選択肢となる。

サーバーやネットワーク機器で考えると、リース、買い取りとしても、本体ハードウェアや回線については専門性の高さから保守、機能保証についてはアウトソースするが、設定情報やソフトウェアについてはインソースで管理することが望ましいことになる。また、クラウドサービスのセキュリティについても、同様な考え方が適用できるはずだ。もちろん、自社のセキュリティスキルや人材リソースによって、インソース、アウトソースの度合いは組織・企業ごとに変わる。

セキュリティ対策やソリューションを導入するとき、まず前提となるのは、その対策が自社にとってどの程度必要なのか、重要なのかである。情報セキュリティマネジメントの基本だが、まず自社に対する脅威とリスクを分析し、それに関係する守るべき企業資産を洗い出す（先に守るべき情報資産をリストするアプローチもある）。守るべき資産には、どのようなセキュリティソリューションがあるのか。

以上を明確にしたうえで、インソースすべきかアウトソースすべきか考えることが重要である。