2022年11月29日、Mike Vizard サイバーセキュリティ純粋主義者にとってゼロトラストITとは、ネットワークに接続されたいかなるユーザーもアプリケーションもマシンも、証明されるまで信用しないというアーキテクチャです。米国立標準技術研究所（NIST）が定義するように、ゼロトラストITとは、「かつて静的なネットワークベースの境界線にあった防御をユーザーと資産、およびリソースに焦点を当てるようにした、一連の進化しつつあるサイバーセキュリティパラダイム」です。したがって、物理的またはネットワーク上の位置や資産の所有権のみに基づいて、資産やユーザーに暗黙の信頼が与えられることはありません。 ほとんどのサイバーセキュリティ専門家にとって、ゼロトラストは決して新しいアイデアではありません。フォレスター・リサーチのアナリストであるジョン・キンダーヴァグが2010年にこの言葉を広めたとされていますが、コンセプト自体は2004年にまでさかのぼることができます。しかし今日、ゼロトラストITは、キャンペーンのスローガンに近いものへと進化しています。ほぼすべての組織が、なんらかのゼロトラストアーキテクチャを採用する方向に向かっています。実際、米国防総省（DoD）はつい最近、今後1年間でゼロトラストIT目標を達成するというビジョンをまとめた37ページの報告書を発表しました。自分の組織のために同様のサイバーセキュリティ戦略を定義しようとしている担当者は、この報告書をコピー＆ペーストするとよいでしょう。 当然のように、ゼロトラスト IT へのシニカルな見方も出てきます。サイバーセキュリティのプラットフォームやサービスを提供するプロバイダはこぞって、サイバーセキュリティ担当者にゼロトラスト IT の目標を達成を促すサービスを売り込みます。しかしサイバーセキュリティの現状を見れば、ゼロトラストITに懐疑や不安の目が向けられても無理はありません。 ただ、懐疑的な見方をしたくなるのはごく自然だとしても、それではより重要な点を見逃してしまいます。サイバーセキュリティ担当者が長い間直面してきた最大の問題の 1 つは、経営陣からのサポートの欠如です。サイバーセキュリティはこれまでずっと、最小化すべきコストとみなされてきました。サイバーセキュリティのなかでも絶対に不可欠だとされる項目にだけ予算が割り当てられてきたのです。一方、「ゼロトラストIT」は、ビジネスリーダーがより理解しやすいキャッチフレーズです。現在の目標は、単にコンプライアンスを達成することではなく、IT 環境を真にロックダウンすることです。そのため、景気後退期であってもサイバーセキュリティに予算を割り当てる傾向がかつてなく高まっています。もちろん、ランサムウェアの台頭も、こうした姿勢の変化に少なからず影響を与えているでしょう。 企業の経営者の関心があるのは、ゼロトラストIT目標をいかに達成するかではありません。成果がすべてなのです。一方、IT担当は、ゼロトラストと聞いて大きくうなずきはしますが、大半はそれが何を意味しているのか正確には理解していません。サイバーセキュリティの観点から最も重要なのは、すべてのステークホルダーがゼロトラストの概念を支持することです。最新の流行語やキャッチフレーズにすぐに飛びつかないほうがカッコいいかもしれませんが、ゼロトラストITキャンペーンはサイバーセキュリティ担当者のためのものではありません。サイバーセキュリティ担当者にとってゼロトラストは、すでに十分に理解されている「多重防衛」の延長線上にあるものです。現在の状況がこれまでと異なるのは、サイバーセキュリティ担当だけでなく、多くの人々がこの議論に参加している点です。 もちろん、どんなスローガンもいずれは空疎に響くことになります。それでもサイバーセキュリティ担当者は、ゼロトラストという言葉が流行している今のうちに、社内のゼロトラストITキャンペーンを開始するとよいでしょう。今ならば次世代サイバーセキュリティ技術への投資をより簡単にとりつけられる、というだけでも十分すぎる理由です。何をすべきかよく理解していない、もちろん感謝もしていない人々に代わってサイバー攻撃と闘い続けるために、セキュリティ担当者たちにはこの新しい技術が大いに必要なのですから。 原文はこちら Vote for Zero Trust early and often November 29, 2022 Mike Vizard https://blog.barracuda.com/2022/11/26/vote-for-zero-trust-early-and-often/
2022年10月31日、Mike Vizard 新しい脆弱性が公開されるときのその方法が変わりつつあります。そのこと自体は称賛されるべきでしょう。先週、OpenSSLプロジェクトの管理者は、とりわけ未知の重要な脆弱性に対処したアップデートを11月1日にリリースすることを発表しました。 ほどなくサイバー犯罪者を含むすべての人が、その脆弱性が何であるかを知ることになるでしょう。しかし、サイバーセキュリティチームにとってこれは、組織が直ちにOpenSSLへの更新プログラムをインストールできるよう準備せよ、という事前警告です。 OpenSSLコミュニティは、Webサイトやアプリケーションで広く利用されているTLS（Transport Layer Security）プロトコルの通信を保護するための暗号化ツールキットの開発を統括しています。最も有名なのは、2014年に発見されたOpenSSLのHeartbleedバグです。このバグを通してサイバー犯罪者は、脆弱なWebサイトやアプリケーションに対して、小さなマルウェアペイロードと大きなlengthフィールドを持つ不正なハートビート要求を送信できるようになりました。 この欠陥の発見が引き起こした混乱は相当なものでした。Heartbleedバグの発見から3年経っても、このバグを悪用した侵害の報告は後を絶ちません。今週公開されるパッチで、多くの企業のセキュリティインシデント対応能力が再び試されることになります。これは、時間との闘いなのです。サイバー犯罪者もまた、今週公開されるであろうOpenSSLの内容について、同じくらい注目していることは間違いないでしょう。 もちろん、脆弱性をどのように公開するかは、多くのサイバーセキュリティの専門家にとって頭の痛い問題です。特にオープンソースのコミュニティは、コミュニティによって維持されているプロジェクトに共通する精神に則って、開示が公に共有されるアプローチを好む傾向があります。しかしここ数年、それはとりわけ困難になってきています。というのも、さまざまなアプリケーションに組み込まれたオープンソースコードの量が飛躍的に増加したためです。多くの IT 組織は、Java アプリケーションからログデータを収集するために広く使用されているオープンソースの Log4J ソフトウェアの脆弱性のすべてのインスタンスをまだ探しています。 プラス面としては、オープンソースのセキュリティ危機が少なくとも無駄になることはないという点です。オープンソースソフトウェアプロジェクトの管理者は、実にさまざまな手段を使うようになっています。コード署名による暗号化もその一つですし、あらゆるコード片のインスタンスがどこで実行されているかを容易に発見できるようにするソフトウェア部品表（SBOM）の自動作成も同様です。 問題は、アクセス可能になった情報をもとに、セキュリティインシデント対応プロセスがどの程度改善されているかということです。ITチームはまず、脆弱性の重大性を判断し、続いて、DevSecOpsのベストプラクティスを適用して最も重要な脆弱性をできるだけ早く修正する必要があります。 今後数カ月の間に、パッチが適用されていないOpenSSLの脆弱なインスタンスに起因するセキュリティ侵害が発生することはほぼ間違いないでしょう。そして、同じくらい明らかなのは、こうしたセキュリティ侵害の発生を防ぐのに必要なアップデートをインストールしなかったことの責任がどこに求められるか、なのです。 原文はこちら Race to patch OpenSSL is on again October 31, 2022 Mike Vizard https://blog.barracuda.com/2022/10/31/race-to-patch-openssl-is-on-again/
