海外ブログ

2022年セキュリティ予測：Fleming Shi（Barracuda Networks本社CTO）

2021年1月6日、Anne Campbell 2022年がはじまり、サイバーセキュリティ業界と脅威にどのような変化、進化、トレンドがもたらされるかを考察しています。2022年に備えるため、バラクーダの3人の役員に話を聞きました。次の12か月に何が待ち受けているか、企業がセキュリティを維持するために何を意識する必要があるかについて、独自の見解と予測を示しています。本稿では、CTOのFleming Shiが、ランサムウェアの進化、コロナパンデミックの継続的な影響、ポストブリーチの時代におけるセキュリティ維持などについての見通しを語っています。サイバーセキュリティや技術分野における、2022年の予測は？ランサムウェアは、今後も問題になると考えられますが、各国政府がランサムウェアに真剣に取り組み、国家レベルで協力し合う姿が見られるようになってきました。このような協力体制下でのより積極的な行動は、ランサムウェアの攻撃者の資金移動力を低下させ、来年の攻撃量に影響を与えるでしょう。しかし、私はまだ、攻撃者がターゲットよりも先んじる「ポストブリーチ（侵入の発見と対処）」の時代にあると考えています。それは、攻撃者が認証情報を含む盗んだデータを手にしているためです。これらの攻撃は、貴重なデータに対する恐喝からソフトウェアのサプライチェーンへの侵入まで多岐にわたります。業務を妨害するだけではなく、企業の信用を失墜させ、信頼の連鎖を破壊するための情報の暴露にまで及んでいます。また、政府がサイバーセキュリティへの取り組みを優先し、ベンダーとの提携関係を構築し、他国とデータを共有することにも再び注目が集まると思います。このようなコラボレーションは、すべての人のセキュリティ向上につながります。 2022年にはどのような脅威が急増するでしょう？引き続き、ランサムウェアがニュースの中心となるでしょう。なぜなら、犯罪者にとって、現在それが最も儲かる方法だからです。政府間の連携や、ベンダーとの提携の促進により、ランサムウェアの被害を食い止める方法を見つけ出すことが、今後の重要な課題となるでしょう。今後、ランサムウェアはどのように進化していくと思われますか？法執行機関や国家レベルでの連携が進み、支払いが滞り始めているため、2022年には、ランサムウェアへの防御について良いニュースを聞くことができると思います。犯罪者にとっては、ランサムウェアの攻撃を仕掛けたところで回収できなければ、たとえ被害者側が支払いや交渉の意思があったとしても、攻撃の可能性を低下させるのに十分な不安と不確実性を与えることができるでしょう。2022年には、グローバルアライアンスとして引き続き協力しあい、これらの資産の移動を確実に遅らせる必要があります。資産の移動を効果的に遅らせることができれば、違いが出てくるはずです。 2022年にセキュリティ上の最大の課題に直面する産業は？重要なインフラは、2022年も引き続き重大なセキュリティ上の課題に直面すると考えられます。この重要なインフラには、エネルギーや金融から、教育、医療まで、あらゆる分野が含まれます。例えば、病院を襲ったランサムウェアの攻撃が、患者の治療に影響を与え、さらには死亡事故につながったという話が数多くあります。重要インフラへの攻撃は、人々の生活に最も直接的な影響を与えるため、サイバー犯罪者がこれらの脆弱な分野に注目し続ける中で、セキュリティは課題となるでしょう。新型コロナウイルスによるパンデミックが、2022年のセキュリティにも影響を与え続けると予測される中で、どのような対策が有効ですか？新型コロナウイルスパンデミックにおいて、サイバー犯罪者が危機的状況を利用して、医療やワクチンのサプライチェーンといった重要なインフラを攻撃しようとしていることがわかりました。今後、病院や医療機関は、ランサムウェア対策の3つのステップ、すなわち、認証情報の漏えい防止、アプリケーションやインフラへのアクセスの確保、データのバックアップを理解する必要があります。それによって、サイバー攻撃による影響をできるだけ少なくして、パンデミックを乗り切ることができるのです。 2022年にITセキュリティ担当者が必要とする、現在は持っていない可能性がある新しいスキルとは？ITセキュリティ担当役員は、フォレンジックとインシデントレスポンスを理解する能力を身につける必要があります。多くのITセキュリティ企業は、大企業であれ、マネージドサービスプロバイダーを利用している小規模企業であれ、あまりにも多くのツールに悩まされ、シグナルを連携させることができていません。2022年以降、ITセキュリティ担当役員の望みを実現するためには、検知と応答がキーワードとなります。この分野の改善には、オープンXDRプラットフォームやサービスプロバイダーによるマネージドXDRソリューションが必要です。これらのツールの利用により、ITセキュリティ担当者は、現在よりも効率的な対応が可能です。現在、多くの企業は、使いこなせないほど多くのツールと情報を持っています。例えば、複数の攻撃対象を保護するツールに投資している企業も見受けられます。今後は、各ツールからのシグナルを収集し、データを相関させることで、実用的な洞察を得ることが重要になります。今日のサイバー攻撃への防御には、予防、検知、対応に至るまで、フォレンジックとセキュリティ分析のスキルが必要となります。そのため、XDR機能を備えたマネージドSoC（Security Operations Center）の活用が、中小企業にとっての解決策となるでしょう。 2022年、セキュリティ市場全体ではどのような変化があるのでしょうか。2022年には、XDRやマネージドディテクション＆レスポンスなど、よりサービスドリブンなツールに市場が移行する中で、データドリブンなプラットフォームの統合が一つの変化となるでしょう。検知と対応はより複雑になるため、多くの企業が不足しているスキルセットに対応する必要があります。多くの企業、特にSMBや中小企業では、この分野を支援する何らかのマネージドサービスが必要になるでしょう。このようなサイバー攻撃から生き残るためには、多額の投資をして社内にチームを構築することなく、効率的かつ効果的に対応するための支援が必要になると思います。そのため、市場の多くはマネージド・セキュリティ・サービス・プロバイダーに移行していくでしょう。企業レベルでは、どのようなツールを使用しているのか、それらのツールからどのようなシグナルを受け取っているのかを把握し、それらのシグナルを統合することで、チームが検知と対応を容易にできるようにすることが必要です。 2022年に普及が予想される新たなセキュリティ技術は？3つの文字、すなわち「XDR」です。XDRとは、「Extended Detection and Response」の略ですが、実際には、他のツールで得られるすべてのテレメトリデータを拡張することを意味します。先に述べたように、XDRの文脈における検知と応答は、多くの組織にとって非常に大きなギャップとなります。このような組織では、検知と応答の支援が必要となり、この新たな技術に対する需要が高まるでしょう。今後数年間で、セキュリティに関するどのような新しい役割が生まれますか？「サイバーセキュリティ・チャンピオン」という新しい役割は、今後数年のうちに、特にソフトウェアを開発している組織で見られるようになるでしょう。開発者、ソフトウェア開発、そしてオープンソース・ライブラリやその他サードパーティ・ライブラリを含むソフトウェア・サプライチェーンを対象とする、いわゆる「シフトレフト」に焦点を当てるセキュリティ・チャンピオンが登場することになるでしょう。ソフトウェア開発ライフサイクル全体の左端に位置し、開発者レベルでセキュリティに注意を払うことで、これらの役割が価値を発揮し始めます。オープンソースのリスクを理解するために、依存関係をスキャンできるソフトウェアツールがあります。こういったツールは、これらの役割が開発者コミュニティ内で推進可能なイニシアチブを生み出します。今後数年間に台頭すると思われるもうひとつの役割は、セキュリティアナリストです。脅威を効果的に検知し、対応するためには、フォレンジックやインシデント対応など、さまざまなシグナルの相関関係を理解し、脅威への対応を実行できるセキュリティアナリストが必要になるでしょう。現在、セキュリティが優先され始めていますが、多くのセキュリティチームがITにレポートするという現在の構造ではなく、ITチームがセキュリティにレポートする時代が来ると思いますか？レポート体制は、組織の成熟度や、CISOが関与しているかどうかなどのリーダーシップによって異なります。ITチームの多くは、セキュリティに対するアプローチがイベントドリブンであるため、当然ながらCISOに報告することはありません。しかし、予測と予防ができ、適切なツールとリソースがあれば、インシデントを防ぐための計画やプログラムを作ることができます。つまり、イベント駆動型のセキュリティアプローチではなく、プロアクティブに対策を講じて、攻撃を未然に防ぐ、あるいは攻撃の連鎖の早い段階で食い止めることで、被害を少なくするという方向にシフトする必要があります。このような変化を起こすには、組織のトップがセキュリティ対策に取り組んでいないと難しいでしょう。 Ebook: 身代金を支払わないために〜ランサムウェア対策のための3ステップ〜原文はこちら：Executive predictions for 2022: CTO Fleming ShiJanuary 6, 2022 Anne Campbell https://blog.barracuda.com/2022/01/06/executive-predictions-for-2022-cto-fleming-shi/

海外ブログ 2022.01.20

Barracuda Cloud-to-Cloud Backupが「2021 CRN Products of the Year」を受賞

海外ブログ 2022.01.12

Barracuda Threat Spotlight（バラクーダが注目する脅威）：ログインジェクション攻撃

トピック：Attacks and Threat Actors 2021年12月22日、Jonathan Tanner インジェクション攻撃は、OWASPの「Webアプリケーションの脆弱性トップ10」に恒常的にランクインしています。SQLインジェクション、コマンドインジェクション、クロスサイトスクリプティング（XSS）攻撃は、一般的に最初に思い浮かぶインジェクション攻撃の形態ですが、ログインジェクションにもリスクがあり、見過ごされている場合があります。ログインジェクションとは、ユーザが操作した入力内容が無害化されずに記録された場合に発生するもので、リモートコード実行（RCE）など、さまざまな影響を及ぼす可能性があります。これは、最近公開されたCVE-2021-44228（別名「log4shell」）log4jに対する攻撃のように、2.15.0より前のバージョンのlog4jや、2.16.0以上で機能が完全に削除される前の2.15.xバージョンでデフォルトのformatMsgNoLookupsプロパティを無視した攻撃がそうでした。脅威のハイライト Log4j ログインジェクション RCE – 攻撃者がログインジェクション攻撃に成功したと仮定すると、JNDIを使ってLDAP検索を行う特別に細工された文字列置換を使って、攻撃者が制御するリモートLDAPサーバから読み込まれたコードを実行することができます。Javaアプリケーションにおけるlog4jの人気の高さと、任意のコードを実行できる能力を考慮して、Apacheはこの脆弱性が公開された際に可能な限り高い深刻度の評価を与えました。この脆弱性により、多くの著名な企業が影響を受けました。詳細開発者やシステム管理者は、ソフトウェアが正常に動作しているかどうかを確認したり、動作していない場合にはより具体的な内容を特定するために、ログの記録はほとんどのアプリケーションやシステムにとって重要な要素です。しかし、ログインジェクションは、アプリケーションやシステム自体のリスクだけではありません。なぜなら、ログが他のソフトウェアによって処理されることはよくあることで、そのソフトウェアもログインジェクションの試みに対して脆弱である可能性があるからです。基本的に、ログファイルに書き込んだり、ログファイルから読み取ったりするものはすべて、ログインジェクション攻撃の標的になる可能性があります。また、ログを読んでいる人も、ログインジェクション攻撃の標的になる可能性があります。ログインジェクション攻撃としては、ログの偽造、サービス拒否、悪意のある文字列のインジェクションなどが考えられますが、これらの攻撃自体にもいくつかの可能性があります。ログの偽造とは、ログに記録されるペイロードを細工して、見た目は正当だが偽のログ行を追加することです。これは、ログ分析システムや、手動でログを読む人（またはイベントシステムを通じてログを読む人）を騙して、実際には起こっていないイベントが起こったと思わせたり、特定のイベントの発生頻度の分析を歪めたりするために使用されます。サービス拒否攻撃では、攻撃者が大量のデータでログファイルを圧倒します。これにより、メモリの枯渇、ディスクスペースの肥大化、あるいは、サイズに基づいてロールバックされ、ファイルのサブセットのみが保持されるログの場合には、ログシステムによってログエントリが早期に削除されることになります。これらのログインジェクション攻撃は、特定のプログラミング言語やテンプレートエンジンを利用する必要はありません。悪意のある文字列インジェクションは、最近公開されたlog4jの脆弱性の場合、リモートコード実行を含め、様々な形態やペイロードを取ることができます。これらの悪意のある文字列は、ロガーやログを読み取るソフトウェアの組み込み機能を悪用することができます。log4shellの場合、文字列置換の側面が悪用されます。具体的には、log4jの式言語を使用して変数を検索し、ログ出力に置換することができる機能です。ログを表示または処理するソフトウェアでテンプレートエンジンが使用されている場合、使用されているテンプレートエンジンの構文を使用してテンプレートインジェクションが可能な場合があります。ログがWebブラウザに表示される場合、テンプレートインジェクションに加えて、Webサービスで使用されているプログラミング言語でコードを注入することが可能な場合があります。例えば、ログが必ずしも攻撃者でなくてもよいユーザに表示されるときに実行されるPHPコードをログに注入することができます。また、ログにJavaScriptを書き込んで、ユーザがWebアプリケーションを介してログエントリを閲覧したときにレンダリングされて実行されるようにする、つまりストアドクロスサイトスクリプティング攻撃も可能です。インジェクション攻撃では、情報漏えいなど様々な結果やリスクが考えられますが、リモートコード実行（RCE）は、脆弱性のより深刻な結果の一つです。RCEは、攻撃者がアプリケーション内のコードを、あたかもアプリケーションの一部であるかのように実行し、アプリケーション自身が利用可能なあらゆるアクセス権や特権を得ることを可能にします。これにより、アプリケーションが利用可能なファイルや、アプリケーションが通信するデータベースへのアクセス、さらにはリバースシェルを介したホストシステム自体へのアクセスが可能になります。ファイルやデータベースへのアクセスは情報漏えいの原因となりますが、シェルは、攻撃者がネットワークにさらに侵入し、アプリケーションがアクセスできる範囲外のシステムやリソースを侵害するための出発点となります。このように、log4shell攻撃が悪用された場合、データとネットワークの両方のセキュリティに深刻な影響を与える可能性があります。ロギングソフトウェアを構築・保守しているグループにとっては、今回の脆弱性により、データサニタイズ機能を組み込む必要性と、セキュリティリスクを考慮してどの程度の機能が有用であるかを検討する必要性が浮き彫りになりました。ほとんどのデータベースクライアントライブラリは、SQLライブラリの「プリペアドステートメント」のようなインジェクション攻撃から保護するために、データサニタイズ機能を提供しています。独自の式言語やテンプレートを持つロギングライブラリの場合、安全ではない可能性のある文字列をロギングする際、ライブラリのユーザに同様の機能を提供することは大変役立ちます。log4shellのような深刻な脆弱性につながる可能性のある機能を数多く利用している場合、保守管理者が検討すべき課題かもしれません。このRCEを可能にする機能が2.16.0で削除されたことを考えると、log4jの保守管理者はすでにこの点に気づいているかもしれません。 log4shellからの保護方法 log4shellから保護するための最善の方法は、少なくともlog4jのバージョン 2.15.0、理想的には2.16.0以上にアップグレードして、この特定のRCEを軽減することです。log4jは直接の依存関係の外でアプリケーションに含まれているかもしれないので、ビルドシステムを使用して依存関係ツリーを入手し、間接的な依存関係としてのlog4jの脆弱なバージョンを確認することができます。「Maven」と「Gradle」は、プロジェクトの依存関係ツリーを印刷するコマンドラインツールを含んでいます。log4jのバージョンが2.10.0以上、2.15.0未満の場合、2.15.0でデフォルトで無効化された機能は、javaコマンドを使用してアプリケーションを実行する際「-Dlog4j2.formatMsgNoLookups=true」フラグを追加することで手動で無効化できます。バージョン2.15.xを使用している場合は、アプリケーションやコマンドのどこかでこのフラグがfalseに上書きされていないかどうかを確認する必要があります。ファイアウォール（ネットワーク、Webアプリケーションを問わず）は、アップグレードの計画と実行に時間がかかる場合の暫定的な対策として、LDAPトラフィックの送信をブロックできる可能性があります。しかし、これらの対策は、この特定の脅威を保護するだけで、ログインジェクション全般を保護するものではありません。Barracuda Web Application FirewallとWAF-as-a-Serviceは、log4shellに関連するものを含むログインジェクションの試みを保護します。ログを使用するすべてのアプリケーションは、たとえそれがlog4jやJavaを使用していなくても、外部からユーザが提供した入力がログに記録されるときに、ログインジェクション攻撃の可能性と、ログの特定の用途に関連する適切なデータサニタイズの実践を確認すべきです。これにより、ログインジェクションに関連して存在する可能性のある他のまたは将来の脆弱性を軽減することができます。サニタイズは、アプリケーションやログシステムの機能を考慮するだけではなく、ログから読み取るものがさらに別の可能性のある脆弱性を引き起こす可能性があるため、単純ではありません。同様に、そもそも何がログに記録されているかということも考慮しなければなりません。例えば、ユーザ名やメールは、インジェクション攻撃を可能にするような特殊文字を許可するケースとしてはリクエストヘッダに比べて妥当性が低いと言えますが、これらの文字を必要とするケースもあります。ログが実際にどのようなシステムで処理されているのか、そのシステムにはどのような脆弱性が存在するのかを考慮することで、ログがもたらすリスクを適切に評価することができます。これは、ログインジェクション攻撃が発生する場所をすべて把握しなくても、その潜在的な影響を理解するのに役立ちます。ログインジェクションは、ログを読み取るすべてのシステムに影響を与える可能性があるため、ログを読み取ったり処理したりしているシステムを追跡することは、ログの記録に関連する特定のリスクを理解するのに役立ちます。また、セキュリティチームや開発チームにとっては、攻撃者がコントロールできるログの内容に関して、どのようなプログラミング、テンプレート、式言語を考慮する必要があるのか絞り込むことができます。レポート：2021年のアプリケーションセキュリティの状況原文はこちら： Threat Spotlight: Log injection attacks December 22, 2021 Jonathan Tanner https://blog.barracuda.com/2021/12/22/threat-spotlight-log-injection-attacks/

海外ブログ 2021.12.28