ブログ(トレンド&インサイト)

目に見えないリスク-サプライチェーンがセキュリティの最優先事項である理由とその対処方法

2014年、OpenSSL暗号ライブラリーの重大なセキュリティー・バグであるHeartbleedが明らかになった時、セキュリティ・コミュニティは破壊的な打撃を受けました。OpenSSLは、機器、Webサーバー、およびサービスとアプリケーションのホスト内のデータコミュニケーションを保護する重要なコンポーネントであったからです。

ユーザーはパッチやアップデートに躍起になり、ハードウェアやソフトウェアベンダーは何百万行ものコードを見直す羽目になりました。ビジネスにも大きな影響を与えたと言えます。

つまりそこには、重大な脆弱性自身が持つよりも、より大きな問題が隠されていたわけです。ひとつは、小規模かつ資金に乏しいチームによって開発された本コードに、多くの人がほぼ無条件に依存していることにありました。もうひとつは、「これだけ多くの人が利用しているコードなのだから、きちんとしたテストがなされ、脆弱性もバグも他の問題もなにもないはずだ」という単純かつ致命的な思い込みにありました。

このコードは、オープンソースのイニシアティブとして公開され、誰もがレビューできる状態にあったものの、セキュリティ研究者が問題を指摘したのは、2012年にその脆弱性が含まれたコードが公開されてから数年後のことでした。

絶え間ない新しいサービス、新しい機能、顧客対応へ要求を満たすよう努力が求められている企業は、より素早い提供の実現のため、サードーパーティーが開発したものを部分的に利用する傾向にあります。これら外部コンポーネントと内部システムとの結びつきが強まるにつれ、それぞれがどこから来たものかを特定することが困難になります。さらに重要なのは、これがサプライチェーンの依存とリスクを象徴している点です。

正式なパートナー関係が多く存在する一方で、レビューされていなかったり、中央管理されたプロセスに則っていない調達が多く存在するはずです。これらの調達は、セキュリティ監査や基本的なチェックすら簡単に回避します。

また、承認を受けたベンダーや技術パートナーとしか取引していなかったとしても、非正式なサプライチェーンの影響を受けてしまう可能性があります。なぜなら、それら正式な取引ベンダーや技術パートナーもまた、良いものをより早く提供するためにサードパーティのソリューションやコードを利用している可能性があるからです。クラウドベースの機能とコードを活用しようとする組織が増えるにつれて、このプロセスはさらに悪化していきます。

対処について

「あらゆるアプリケーションやコードを、徹底的にテストし、レビューすることは、現実的に不可能である」という事実を、まず受け入れることからはじめましょう。これは、セキュリティチームが日常的に経験している、アラートの過負荷問題に似ています。全てを検証することはできないのです。

しかし、異なる視点からものごとを見つめ、重大な脅威を特定するプロセスを合理化するためのインテリジェンス主導のアプローチを取ることで、膨大な数のイベントに立ち向かうセキュリティチームと同様のアプローチで、サプライチェーンリスクを軽減する一歩を踏み出すことができるのです。

コード行の数よりも、当然コードを提供しているベンダーやパートナー、サードパーティの数のほうが圧倒的に少ないわけです。これらの企業との関係の文書化は、数日で達成できるような単純なタスクではありませんが、人によって成し遂げられるタスクであり、これらの関係を文書化する必要性の認識が広まり、様々な活動に統合されるにつれ、改善していきます。

これらの関係が文書化されば、組織自体やサプライチェーンの一部である第三者、主要幹部、貢献者などに関する記事、フォーラム、その他のサイトでの記述をスキャンすることによって、問題、評価、ブランド、およびその他の懸念についてモニタリングすることができます。

この作業は手動で行うには面倒な可能性がありますが、同様の情報を提供するサービスがあり、通常、これはデジタル脅威とブランド監視サービスの一部として提供されます。これらのサービスを検討している組織の大半は、自社のブランド、役員などに関する情報収集を目的としていますが、同様にパートナーやサードパーティなどにも適用できます。

このサービスによって提供される情報と、環境内のコンポーネントで発生する可能性のある問題を監視する脅威インテリジェンスデータを組み合わせることで、サプライチェーンに関連する潜在的な脅威とリスクを可視化することができるようになります。この情報は、定期的に評価やリスクスコアをアップデートする基礎情報として用いることもでき、実際にリスクが危険域に達する前に、その芽を発見し、対処することも可能にします。これは、潜在的な問題を軽減し、回避するためにスケーラブルアプローチを導入する唯一の方法です。

まとめ

自社製品などの主要機能や提供製品のコンポーネントやプラットフォーム、サービスやその他の要素をサードパーティに頼るようになるにつれ、自身のサプライチェーンに関わるリスクを監視するためのプロセスを、セキュリティプログラムに取り入れていく必要があります。