サイバーセキュリティにおける「内部関係者による脅威」は、ハッカーによる外部からの攻撃ではなく、組織内の人物による、有害となる恐れのある行為を指す言葉です。内部関係者が、データを盗んだり損害を与えたりしようとして、悪意を持って行動することがあります。あるいは、間違いであるという事実や行動による結果を理解しない内部関係者が、リンクをクリックしたり、情報を共有したりすることで、偶発的に誤った行為をしてしまう場合もあります。企業にとっての課題は、従業員が各自の職務を遂行できるようにし、同時に、内部関係者によるセキュリティの問題につながる行為から会社を保護する方法を見つけることです。

内部関係者の脅威の具体的なリスク

内部関係者によってもたらされる損害の可能性と被害の規模の見極めにあたっては、過去の実例が参考になるでしょう。内部関係者によって発生する被害の度合いは、システムにアクセスする人の意図や、その人がアクセスできる情報を使って何ができるのかによって異なります。内部関係者の行動によって発生する可能性があるビジネスリスクとその被害を組織が判断する際には、次のような実例が参考になるでしょう。

• テュークスベリー病院では、1 人の職員が、誰にも気付かれることなく、14 年間にわたって患者レコードに不正アクセスしていた。
• モルガン・スタンレーでは、1 人の従業員が何年もの間、70 万件もの顧客口座にアクセスしていた。
• UMass 記念医療センターは、12 年もの間、データの不正アクセスに気付かなかった。データ漏洩に関与した内部関係者が、不正取得した患者データを使って携帯電話やクレジットカードの口座を開設していた可能性がある。
• サンフランシスコ市では、ネットワーク管理者が市のネットワークをアクセス不能にする事件が発生したことがある。
• グッチでは、解雇されたエンジニアが、ソーシャルエンジニアリングを使用して IT 担当者を騙し、サーバのシャットダウンとデータの削除を許可するように仕向けていた。
• 匿名の Amazon 関係者の目撃談として、アカウントのセキュリティが正しくないために顧客のデータが削除されてしまったことがあったが、すぐにその問題を改善することはできなかった。
• オメガでは、解雇されたコンピュータプログラマが不正ソフトウェアをインストールしたために、会社は 1,000 万ドルの損害を被った。また、その元従業員には懲役 41 ヶ月が言い渡された。
• 大々的に報道されたように、エドワード・スノーデンによって、米国のいくつかの最高機密文書が公開された。
• Peter Kroger という名前でも知られている Morris Cohen は、ロスアラモス研究所から原子爆弾の計画書を盗んで、ロシア政府に提供した。
• Silvermaster Group を始めとするスパイ組織は、冷戦時代に米国政府機関に勤務して、協力者を雇ったり、機密データを漏洩したり、米国政府の決定に影響を与えたりしていた。その活動は、「Encyclopedia of Cold War Espionage, Spies, and Secret Operations」で詳しく説明されている。

組織の不利益になる行為を行った内部関係者の例は枚挙に暇がなく、少し調べれば、これ以外にもたくさん見つかるはずです。内部関係者による脅威は、解決しなければならない厄介な問題ではありますが、その一方で、雇用主は従業員を信頼し、各自の職務を滞りなく遂行してもらいたいと考えるものです。従業員に面倒な手続きを強制すれば、業務が停滞し、ビジネスに影響するでしょう。とは言え、データ漏洩や業務妨害から会社を保護し、否定的な報道を最小限にとどめる努力も必要です。厄介な問題ではありますが、いくつかの対策を実施することで、内部関係者による脅威から企業や組織を保護できます。

意識の向上

どのようなセキュリティプログラムであっても、導入を成功させるためには、企業や組織の責任者、あるいはビジネスオーナーが、内部関係者による脅威の存在を認識する必要があります。企業や組織の責任者は、ビジネスの保護に最適なセキュリティプログラムを判断し、購入し、導入する必要があります。さらには、ビジネスオーナー自身もセキュリティプログラムの価値を認め、確実な施行を支援する必要があります。

セキュリティポリシー

従業員がするべきこと、してはならないことを具体的に文書化して、セキュリティポリシーに記載します。これは、どのような行為が損害につながる可能性があるのかを、従業員が理解していない場合もあるためです。不適切なアクセスは、悪意による行動と言うよりも、好奇心からくるものである可能性もあります。従業員が、自分の仕事をしたり、誰かを助けてあげたりする目的で危険な行為を行い、その行為がもたらす結果を理解していなかったという場合もあります。以前に私が出席したセキュリティクラスの受講生は、NSA で働いていたことがあり、エドワード・スノーデンはいい奴だったが、流出した文書を手に入れるための認証情報を教えるように同僚に頼んでいたと話していました。この記事には、民間人のある NSA 職員が無意識にスノーデンを助けてしまっただけであり、彼自身に文書を盗もうという意図はなかったと説明されています。

ポリシーがあれば、従業員は、自分自身が取るべき行動を簡単に判断できます。ポリシーがあれば、従業員が規則に従って行動するようになり、ソーシャルエンジニアリングを使って情報を聞き出そうとする誘いを断ろうと考えるようになるでしょう。ポリシーが文書化されていなかったり、雇用主がポリシーの存在を従業員に知らせていなかったりすると、違反行為を判断する根拠を提示できません。また、従業員がポリシーに従っていないこと、ポリシーが常に施行されていることの確かな証拠を提示できるようにしておきます。

トレーニング

文書を配布して従業員に署名させるだけでは、効果的なトレーニングとは言えません。従業員は忙しく、仕事に追われています。私は以前に、SANS Institute のセキュリティ意識啓発トレーニングに参加したことがありますが、そこでは、従業員を対象とする効果的なセキュリティ意識向上プログラムを雇用主が作成する際に役立つ具体的な情報を学ぶことができました。セキュリティチームが利用できる、セキュリティトレーニングに役立つ様々なツールも存在します。また、具体的な事例も役に立つでしょう。行動を変化させるという観点からは、従業員が仕事をする際に使用するプロセスにセキュリティトレーニングを組み込むことで効果が上がります。これについては、セキュアクラウドの導入に関する論文、「Balancing Security and Innovation With Event Driven Automation（イベント駆動の自動化によるセキュリティとイノベーションの両立）」を参照してください。

職務の分離

職務の分離または職務の分割とは、作業を構造化して、1 つの仕事を必ず何人かで終わらせるようにすることを言います。財務プロセスには、しばしばこの原則が採用されていますが、組織においても、この原則を IT システムの設計に当てはめることができます。私がこれまでに読んだり、コンサルタントあるいは従業員として経験したり、個人的に実践したりしたことがあるいくつかの実例を、以下にご紹介します。

• ある製薬会社は、新薬を海外で開発し、製造工場を別の場所に置くようにした。どちらの場所にも、完全な数式はないため、どちらの従業員も、自分がアクセスできるシステムから完全な数式を盗むことはできない。
• ある会社は、社会保障番号を 2 つに分割し、それぞれを別のデータベースに保存するようにし、異なる従業員が異なるデータベースにアクセスするようにした。この設計では、システムが完全な社会保障番号をログファイルに書き込まないようにし、同時に、メモリ内での処理中は社会保障番号が保護されるようにする必要があった。また、ユーザに完全な社会保障番号を表示しないように、アプリケーションを設計した。
• チームを分けて職務を分割することで、管理が一極に集中しないようにする。たとえば、アカウントとデータにアクセスするためのアクセス権を作成するチームとデータを処理するチームに分けて、それぞれのチームで暗号鍵を管理するようにする。
• システムアーキテクチャと組織構造によって、機密データにアクセスするコードの開発をいくつかのチームに分散させるようにし、チームごとにコードの異なる部分を所有して、別々のソースコードリポジトリにそのコード部分を入れるようにする。
• ソフトウェア開発、品質保証、および本番運用の環境とチームを分ける。システムを所有するチームだけがそのシステムを変更できるようにする。
• たとえば、本番環境に一時アクセスを認める方法を導入し、その環境の監視を外部の A 社に、承認を B 社に依頼するという方法が考えられる。
• 職務に必要とされないデータを、匿名化する、または表示を制限する。たとえば、トランザクション処理の担当者が顧客のクレジットカード番号を知る必要はない。病院の支払窓口の担当者が患者の処方箋、病気、あるいは社会保障番号を知る必要はない。
• システムで、PII（個人識別可能情報）とデータ処理を分離する方法もある。たとえば、システムで SAAS ソリューションのログを表示する部分がそのログの所有者の詳細を知る必要はない。マイクロサービスの利用は、このようなシステム設計に適している。
• 「CloudFormation によるセキュア AWS 展開のメリット」という以前の記事で説明したように、AWS のツールを使ってクラウドを展開すると、ロギングシステムが分離され、システムのその部分が Amazon によって処理されるようになるため、会社の従業員が変更できなくなる。

組織や会社によって差があるため、重要なプロセスやデータが何であるかを、それぞれが判断する必要があります。最も保護を必要とするものが特定されたら、関連するシステムとプロセスを設計し、従業員またはシステムがその仕事をするために必要なものだけにアクセスを制限します。また、すべてのシステムとデータにアクセスできる権限を一人に与えることのない組織構造を実装します。そして、機密データを処理するプロセスに相互牽制の仕組みを組み込みます。

監視

「信頼せよ、されど確認せよ」は、ロナルド・レーガンが冷戦時代にミハイル・ゴルバチョフとの交渉でよく使った言葉として知られていますが、元々は、ロシアの古くからある諺です。従業員を信用しなかったり、厳格なシステムを作ってルールを強制したりするのではなく、セキュリティ関連の行動を監視し、警告するように設定しておきます。会社のポリシーに違反して行動する従業員には、追加トレーニングを受けさせるようにし、何回もセキュリティポリシーに違反した従業員には、ポリシーに明記した方法で指導します。

監視にあたっては、組織の所在地やビジネスを行う場所で施行されている個人情報保護法を遵守する必要があります。監視システムから信頼できるデータを取得できるようにするには、監視システムそのものが安全でなければなりません。技術的な制御だけに頼って監視するのではなく、人間が関与する必要があります。以前に執筆した、大手スーパー、ターゲット社における情報漏洩に関するホワイトペーパーで述べましたが、防犯カメラを設置しても、誰も監視しなければ役に立ちません。社内あるいは社外の誰かがログデータやアラートを検証する必要があります。そして、そのデータをその従業員の上司や社内のセキュリティチームに転送するようにしたり、外部の MSSP（マネージドセキュリティサービスプロバイダ）に監視を委託したりすることもできます。

インシデント対応

問題発生時に、皆さんの会社では、どのように対応されるのでしょうか。常勤のセキュリティ担当者がいない中小規模企業においては、MSSP の活用も一つの有効な手段となるでしょう。前述のターゲット社には第三者の監視会社がいましたが、情報漏洩が発生した際の対応が遅れました。情報漏洩が発生した場合、皆さんはどうされるでしょうか。運用を迅速に復旧するためのバックアップがありますか？内部関係者の行動を追跡するためのログがありますか？ログが確実に残っていますか？ 削除されたり変更されたりしている恐れはありませんか？以上の点を事前に確認しておけば、問題発生時に、最小限の被害で復旧が可能になります。

内部関係者による脅威からの保護が全員の保護につながる

内部関係者による脅威への対策を計画することは、企業や組織だけでなく、顧客やその従業員にとっての利益にもなります。企業や組織にとっては、データ漏洩に伴う否定的報道や金銭的損失などから自らを保護できるというメリットがあります。顧客にとっては、自らのデータが保護されるというメリットがあります。従業員にとっては、わかりやすく規定されたポリシーに従い、そのポリシーの存在理由を理解しておけば、簡単かつ安心して業務を遂行できるというメリットがあります。ポリシーを用意し、その規則に従って行動するように従業員を指導することで、悪意のある誰かに騙されたり、不正行為を強要されたりする可能性が低くなります。システムアーキテクチャとプロセス設計によって、データ漏洩を制限できます。監視には、望ましくない行動に対する警告という効果があります。そして、従業員をセキュリティ強化の取り組みに参加させることで、セキュリティプログラムの効果が上がり、一人一人がセキュリティの強化に貢献できるようになるでしょう。— Teri Radichel（@teriradichel）